Jump to content

Talk:Calculus of constructions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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]