Talk:Calculus of constructions

Latest comment: 1 month ago by 2A00:1FA2:82F9:3AFA:0:4D:730:AF01 in topic Definition of "small" and "large" types

Total

edit

CoC can represent all functions provably total in higher-order logic, right? So, in what system is the strong normalization theory proved? Jim Apple 08:03, 19 August 2005 (UTC)Reply

From the freely online accessible paper, I see no special care about this, even if the proof is not given. However, it does not seem that strong normalization is equivalent to consistency; they are both stated as corollaries of the same, rather technical theorem (whose proof is not included - the full reference given there is a PhD thesis in French). --Blaisorblade (talk) 01:14, 20 June 2008 (UTC)Reply
Exаmine mу results, this is the extent of my earnings. 2A0D:3344:1402:E10:AB91:8D9F:819D:DCE (talk) 09:07, 20 July 2024 (UTC)Reply

Deficiencies in the article

edit

The inference rules presented in this article seem deficient. In particular, there is no way to prove anything of the form   from them. I imagine what's missing is a rule allowing one to derive   from a derivation of   and the beta-equality of   and  , or something like that. Hopefully, someone more familiar with this material can clear things up. -Chinju 17:41, 2 November 2005 (UTC)Reply

The online article (Coquand and Huet, 1986) states an obvious inference rule to prove typing for variables (they have the type declared in  ), and states as a lemma (lemma 5 on page 7) that "if   and  , then  ). I can't find the deduction rule you would like to have, but it should be surely a theorem, not a rule (even because typing judgements are introduced before conversion rules; conversion rules is the equivalent of beta-conversion in that article).--Blaisorblade (talk) 01:14, 20 June 2008 (UTC)Reply
I retract my previous comment. The article has been changed significantly, and it now indeed includes a conversion typing rule, that is, "a rule allowing one to derive   from a derivation of   and the beta-equality of   and  ", as Chinju wrote. (It has the extra condition that   for whatever technical reasons — but that might need a citation). I even misquoted Lemma 5 above: it should read  . In the paper, the rule of conversion is the one asked for by Chinju, and does not need that side condition. However, that side condition is often needed (depending on the details of the formalization), for instance it is needed in pure type systems. --Blaisorblade (talk) 21:59, 10 August 2014 (UTC)Reply

The whole article seem to miss many definitions or assume to get them from lambda calculus. When terms are defined, variables are not at all introduced. At a first look at the freely available paper, one sees no way to fully reconcile the article with the paper (in particular, it is not sufficient to assume that M and N are terms to form the term  ). The rules of conversion are omitted from the article; and so on. I'm marking this with the {{expert}} template.--Blaisorblade (talk) 00:46, 20 June 2008 (UTC)Reply

A note: I know lambda-calculus and have read about Curry-Howard isomorphism, but I'm not at all an expert in the subject (particularly, in the calculus of constructions - I've just tried browsing the article to make sense of it). --Blaisorblade (talk) 01:14, 20 June 2008 (UTC)Reply

Equiconsistency with ZFC

edit

I removed the claim that the CoC was equiconsistent with ZFC because the paper cited ("Sets in types, types in sets") doesn't prove this. It uses a stronger type theory with inductive types, the calculus of inductive constructions. If ZFC[i] is ZFC with i inaccessible cardinals and CIC[i] is the calculus of inductive constructions with sorts Prop, Type1, ..., Typei, then the paper constructs a model of CIC[i] (plus choice and excluded middle axioms) in ZFC[i-1] and a model of ZFC[i] in CIC[i+2] (plus choice and excluded middle axioms.) Spacepotato (talk) 03:17, 3 February 2022 (UTC)Reply

Clarification needed for notation

edit

What do the notations

  •  ,
  •  , and
  •  

mean? The are not defined anywhere in the article. The-erinaceous-one (talk) 22:20, 24 February 2023 (UTC)Reply

They represent function application, lambda-abstraction, and dependent product formation, respectively. Spacepotato (talk) 19:24, 17 April 2023 (UTC)Reply

On the page Lambda cube, the calculus of constructions uses the   operator instead of  . It's my understanding that the use of   in, e.g. System F or Hindley–Milner, gets translated as  , i.e. "for all types X, T[X] is a type", so the   operator is more general. Does this need to be fixed, or is   being used in a "punning" way? Metaweta (talk) 16:06, 24 May 2023 (UTC)Reply

In this context, there is not much difference between   and  . You can use whichever you prefer. Spacepotato (talk) 17:35, 31 July 2023 (UTC)Reply

Definition of "small" and "large" types

edit

These terms are not defined on this page, nor anywhere else on Wikipedia as far as I can tell. They should either be defined or removed. Ablueberry87 (talk) 01:49, 6 January 2024 (UTC)Reply

Bold 5.139.227.97 (talk) 11:56, 7 April 2024 (UTC)Reply

@ 2A00:1FA2:82F9:3AFA:0:4D:730:AF01 (talk) 14:53, 13 October 2024 (UTC)Reply