<p>A possible reason for the difference, as your own remarks hint, is impredicativity. Coq historically had an impredicative set (still available as a flag i believe!)</p>

<p>Quoting Adam Chlipala's book <a href="http://adam.chlipala.net/cpdt/html/Universes.html" rel="nofollow">http://adam.chlipala.net/cpdt/html/Universes.html</a></p>

<blockquote>
  <p>The Coq tools support a command-line flag -impredicative-set, which modifies Gallina in a more fundamental way by making Set impredicative. A term like forall T : Set, T has type Set, and inductive definitions in Set may have constructors that quantify over arguments of any types. To maintain consistency, an elimination restriction must be imposed, similarly to the restriction for Prop. The restriction only applies to large inductive types, where some constructor quantifies over a type of type Type. In such cases, a value in this inductive type may only be pattern-matched over to yield a result type whose type is Set or Prop. This rule contrasts with the rule for Prop, where the restriction applies even to non-large inductive types, and where the result type may only have type Prop.
  In old versions of Coq, Set was impredicative by default. Later versions make Set predicative to avoid inconsistency with some classical axioms. In particular, one should watch out when using impredicative Set with axioms of choice. In combination with excluded middle or predicate extensionality, inconsistency can result. Impredicative Set can be useful for modeling inherently impredicative mathematical concepts, but almost all Coq developments get by fine without it.</p>
</blockquote>

CC BY-SA 3.0
2013-08-30T18:46:52.377Z
From the sound of the bug fix I found above, it sounds like Agda simply wasn't checking positivity of indices for constructor results.  Which doesn't actually indicate whether my proposed type in monotone, but suggests it isn't related to impredicativity.
Colin Gordon
CC BY-SA 3.0
2013-08-30T18:47:51.630Z
And yes, -impredicative-set makes Set impredicative in Coq.
Colin Gordon
CC BY-SA 3.0
2013-08-30T04:03:32.527Z
2013-08-30T04:03:32.527Z
Carter Tazio Schonwald
<p>The issue seems to be confusion resulting from a confluence of two factors:</p>

<ol>
<li>I was using a stale version of Agda (2.3.0.1).  It appears that prior to 2.3.2, Agda simply wasn't checking strict positivity of the indices of constructor results (see the bug I linked elsewhere in the thread).</li>
<li>A closer reading of Dybjer's <a href="http://scholar.google.com/scholar?cluster=4782447773494298397&amp;hl=en&amp;as_sdt=0,48">Inductive Families</a> paper suggests that he may have intended that the inductive type being defined <em>not be bound when typing the indices of a constructor result</em>.  Section 3.2.1 gives the scheme for inductive constructors in prose, and apparently I misread the language describing the binding environments of each portion of the scheme.</li>
</ol>

<p>This closer reading is of course consistent with the check that Coq and (recent versions of) Agda perform, that prohibit any appearance of T in its own indices.</p>

CC BY-SA 3.0
2013-09-02T03:45:49.070Z
2013-09-02T03:45:49.070Z
Colin Gordon
<p>I've stumbled across a confusing disagreement between Agda and Coq that is not obviously related to the most well known distinctions between their type theories (e.g., (im)predicativity, induction-recursion, etc.).</p>

<p>In particular, the following definition is accepted by Agda:</p>

<pre><code>  data Ty : Set0 -&gt; Set0 where
    c1 : Ty ℕ
    c2 : Ty (Ty ℕ)
</code></pre>

<p>whereas the equivalent Coq definition is rejected because the appearance of [Ty _] as an index of itself in c2 is considered to violate strict positivity.</p>

<pre><code>  Inductive Ty : Set -&gt; Set :=
    | c1 : Ty nat
    | c2 : Ty (Ty nat).
</code></pre>

<p>In fact, this case is almost verbatim an example from Coq'Art Section 14.1.2.1 of violating strict positivity:</p>

<pre><code>  Inductive T : Set -&gt; Set := c : (T (T nat)).
</code></pre>

<p>But I don't see the reasons for this difference between the type theories.  The classic example of proving False using a negative occurrence of a type in a constructor argument is clear to me, but I can't see how one might derive a contradiction from this style of indexing (regardless of otherwise strictly positive constructor arguments).</p>

<p>Poking around the literature, Dybjer's early Inductive Families paper makes an offhand comment about Paulin-Mohring's solution in the CID paper having slightly different restrictions, and vaguely suggests the differences might be related to impredicativity, but doesn't elaborate further.  Dybjer's paper seems to allow this, while Paulin-Mohring's clearly prohibits it.</p>

<p>Apparently I'm not the first to notice this difference of opinion, and some believe this definition shouldn't be permitted in either system (<a href="https://lists.chalmers.se/pipermail/agda/2012/004249.html">https://lists.chalmers.se/pipermail/agda/2012/004249.html</a>), but I haven't found any explanations of why it is either sound in one system but not the other, or just a difference of opinion.</p>

<p>So I suppose I have several questions:</p>

<ol>
<li>Is this an example of a monotone, but non-strictly-positive type? (In Coq; clearly Agda considers it strictly positive)</li>
<li>Why does Agda permit this while Coq rejects it?  It is simply an idiosyncratic difference in the interpretation of "strictly positive," is there a subtle difference between Coq and Agda that makes it sound in Agda and unsound in Coq, or is it a matter of taste driven by particular theoretical preferences?</li>
<li>Is there a meaningful difference between the first definition above, and the equivalent inductive-recursive definition below?</li>
</ol>

<p>Inductive-recursive definition:</p>

<pre><code>  mutual
    data U : Set0 -&gt; Set0 where
      c : (i : Fin 2) -&gt; U (T i)
    T : Fin 2 -&gt; Set0
    T zero = ℕ
    T (suc zero) = U ℕ
</code></pre>

<p>I'm happy to have pointers to relevant literature.</p>

<p>Thanks in advance.</p>

CC BY-SA 3.0
2013-08-29T23:43:53.860Z
As far as I know, Coq is stricter than what the underlying theory allows, because it was easier to implement and useful enough in practice. [This answer about a different but related case](http://cs.stackexchange.com/questions/104/recursive-definitions-over-an-inductive-type-with-nested-components/120#120) is as far as my understanding goes.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2013-08-30T16:42:17.787Z
This definition is not accepted by the current dev version of Agda: `Ty is not strictly positive, because it occurs in an index of the target type of the constructor c2 in the definition of Ty.`
gallais
CC BY-SA 3.0
2013-08-30T18:03:50.510Z
Yes, you're right, someone else pointed this out to me last night.  I had been using Debian's 2.3.0.1 package, but 2.3.2.1 from Cabal rejects both the direct and IR definitions.  It looks like a seemingly unrelated bug made positivity checking on indices stricter: https://code.google.com/p/agda/issues/detail?id=690

Since it was discussed on the list without explicitly being marked a soundness issue, I'm still wondering if the type itself is sound.
Colin Gordon
<type-theory><coq>
Why do Agda and Coq disagree on strict positivity?
Colin Gordon
# Why do Agda and Coq disagree on strict positivity?

(Asked by: username_0 on 2013-08-29)

I've stumbled across a confusing disagreement between Agda and Coq that is not obviously related to the most well known distinctions between their type theories (e.g., (im)predicativity, induction-recursion, etc.).
In particular, the following definition is accepted by Agda:
  data Ty : Set0 -> Set0 where
    c1 : Ty ℕ
    c2 : Ty (Ty ℕ)

whereas the equivalent Coq definition is rejected because the appearance of [Ty _] as an index of itself in c2 is considered to violate strict positivity.
  Inductive Ty : Set -> Set :=
    | c1 : Ty nat
    | c2 : Ty (Ty nat).

In fact, this case is almost verbatim an example from Coq'Art Section 14.1.2.1 of violating strict positivity:
  Inductive T : Set -> Set := c : (T (T nat)).

But I don't see the reasons for this difference between the type theories.  The classic example of proving False using a negative occurrence of a type in a constructor argument is clear to me, but I can't see how one might derive a contradiction from this style of indexing (regardless of otherwise strictly positive constructor arguments).
Poking around the literature, Dybjer's early Inductive Families paper makes an offhand comment about Paulin-Mohring's solution in the CID paper having slightly different restrictions, and vaguely suggests the differences might be related to impredicativity, but doesn't elaborate further.  Dybjer's paper seems to allow this, while Paulin-Mohring's clearly prohibits it.
Apparently I'm not the first to notice this difference of opinion, and some believe this definition shouldn't be permitted in either system (https://lists.chalmers.se/pipermail/agda/2012/004249.html), but I haven't found any explanations of why it is either sound in one system but not the other, or just a difference of opinion.
So I suppose I have several questions:

Is this an example of a monotone, but non-strictly-positive type? (In Coq; clearly Agda considers it strictly positive)
Why does Agda permit this while Coq rejects it?  It is simply an idiosyncratic difference in the interpretation of "strictly positive," is there a subtle difference between Coq and Agda that makes it sound in Agda and unsound in Coq, or is it a matter of taste driven by particular theoretical preferences?
Is there a meaningful difference between the first definition above, and the equivalent inductive-recursive definition below?

Inductive-recursive definition:
  mutual
    data U : Set0 -> Set0 where
      c : (i : Fin 2) -> U (T i)
    T : Fin 2 -> Set0
    T zero = ℕ
    T (suc zero) = U ℕ

I'm happy to have pointers to relevant literature.
Thanks in advance.

**Tags:** type-theory, coq

> **Comments:**
> **username_1**: As far as I know, Coq is stricter than what the underlying theory allows, because it was easier to implement and useful enough in practice. [This answer about a different but related case](http://cs.stackexchange.com/questions/104/recursive-definitions-over-an-inductive-type-with-nested-components/120#120) is as far as my understanding goes.  
> **username_2**: This definition is not accepted by the current dev version of Agda: `Ty is not strictly positive, because it occurs in an index of the target type of the constructor c2 in the definition of Ty.`  
> **username_0**: Yes, you're right, someone else pointed this out to me last night.  I had been using Debian's 2.3.0.1 package, but 2.3.2.1 from Cabal rejects both the direct and IR definitions.  It looks like a seemingly unrelated bug made positivity checking on indices stricter: https://code.google.com/p/agda/issues/detail?id=690  Since it was discussed on the list without explicitly being marked a soundness issue, I'm still wondering if the type itself is sound.  

---

## 2 answers

### Answer by username_0 on 2013-09-02. Score: 12 | Accepted answer

The issue seems to be confusion resulting from a confluence of two factors:

1. I was using a stale version of Agda (2.3.0.1). It appears that prior to 2.3.2, Agda simply wasn't checking strict positivity of the indices of constructor results (see the bug I linked elsewhere in the thread).
2. A closer reading of Dybjer's [Inductive Families](http://scholar.google.com/scholar?cluster=4782447773494298397&hl=en&as_sdt=0,48) paper suggests that he may have intended that the inductive type being defined *not be bound when typing the indices of a constructor result*. Section 3.2.1 gives the scheme for inductive constructors in prose, and apparently I misread the language describing the binding environments of each portion of the scheme.

This closer reading is of course consistent with the check that Coq and (recent versions of) Agda perform, that prohibit any appearance of T in its own indices.


---

### Answer by username_3 on 2013-08-30. Score: 4

A possible reason for the difference, as your own remarks hint, is impredicativity. Coq historically had an impredicative set (still available as a flag i believe!)

Quoting Adam Chlipala's book <http://adam.chlipala.net/cpdt/html/Universes.html>

> The Coq tools support a command-line flag -impredicative-set, which modifies Gallina in a more fundamental way by making Set impredicative. A term like forall T : Set, T has type Set, and inductive definitions in Set may have constructors that quantify over arguments of any types. To maintain consistency, an elimination restriction must be imposed, similarly to the restriction for Prop. The restriction only applies to large inductive types, where some constructor quantifies over a type of type Type. In such cases, a value in this inductive type may only be pattern-matched over to yield a result type whose type is Set or Prop. This rule contrasts with the rule for Prop, where the restriction applies even to non-large inductive types, and where the result type may only have type Prop.
> In old versions of Coq, Set was impredicative by default. Later versions make Set predicative to avoid inconsistency with some classical axioms. In particular, one should watch out when using impredicative Set with axioms of choice. In combination with excluded middle or predicate extensionality, inconsistency can result. Impredicative Set can be useful for modeling inherently impredicative mathematical concepts, but almost all Coq developments get by fine without it.

> **Comments:**
> **username_0**: From the sound of the bug fix I found above, it sounds like Agda simply wasn't checking positivity of indices for constructor results.  Which doesn't actually indicate whether my proposed type in monotone, but suggests it isn't related to impredicativity.  
> **username_0**: And yes, -impredicative-set makes Set impredicative in Coq.  

---

