comparison src/Universes.v @ 233:f15f7c4eebfe

Mention fake universe polymorphism
author Adam Chlipala <adamc@hcoop.net>
date Mon, 30 Nov 2009 14:21:34 -0500
parents bc0f515a929f
children be571572c088
comparison
equal deleted inserted replaced
232:d1e0a6d8eef1 233:f15f7c4eebfe
289 289
290 Error: Universe inconsistency (cannot enforce Top.51 < Top.51). 290 Error: Universe inconsistency (cannot enforce Top.51 < Top.51).
291 291
292 ]] 292 ]]
293 293
294 The key benefit parameters bring us is the ability to avoid quantifying over types in the types of constructors. Such quantification induces less-than constraints, while parameters only introduce less-than-or-equal-to constraints. *) 294 The key benefit parameters bring us is the ability to avoid quantifying over types in the types of constructors. Such quantification induces less-than constraints, while parameters only introduce less-than-or-equal-to constraints.
295
296 Coq includes one more (potentially confusing) feature related to parameters. While Gallina does not support real universe polymorphism, there is a convenience facility that mimics universe polymorphism in some cases. We can illustrate what this means with a simple example. *)
297
298 Inductive foo (A : Type) : Type :=
299 | Foo : A -> foo A.
295 300
296 (* begin hide *) 301 (* begin hide *)
297 Unset Printing Universes. 302 Unset Printing Universes.
298 (* end hide *) 303 (* end hide *)
304
305 Check foo nat.
306 (** %\vspace{-.15in}% [[
307 foo nat
308 : Set
309 ]] *)
310
311 Check foo Set.
312 (** %\vspace{-.15in}% [[
313 foo Set
314 : Type
315 ]] *)
316
317 Check foo True.
318 (** %\vspace{-.15in}% [[
319 foo True
320 : Prop
321
322 ]]
323
324 The basic pattern here is that Coq is willing to automatically build a "copied-and-pasted" version of an inductive definition, where some occurrences of [Type] have been replaced by [Set] or [Prop]. In each context, the type-checker tries to find the valid replacements that are lowest in the type hierarchy. Automatic cloning of definitions can be much more convenient than manual cloning. We have already taken advantage of the fact that we may re-use the same families of tuple and list types to form values in [Set] and [Type].
325
326 Imitation polymorphism can be confusing in some contexts. For instance, it is what is responsible for this weird behavior. *)
327
328 Inductive bar : Type := Bar : bar.
329
330 Check bar.
331 (** %\vspace{-.15in}% [[
332 bar
333 : Prop
334
335 ]]
336
337 The type that Coq comes up with may be used in strictly more contexts than the type one might have expected. *)
299 338
300 339
301 (** * The [Prop] Universe *) 340 (** * The [Prop] Universe *)
302 341
303 (** In Chapter 4, we saw parallel versions of useful datatypes for "programs" and "proofs." The convention was that programs live in [Set], and proofs live in [Prop]. We gave little explanation for why it is useful to maintain this distinction. There is certainly documentation value from separating programs from proofs; in practice, different concerns apply to building the two types of objects. It turns out, however, that these concerns motivate formal differences between the two universes in Coq. 342 (** In Chapter 4, we saw parallel versions of useful datatypes for "programs" and "proofs." The convention was that programs live in [Set], and proofs live in [Prop]. We gave little explanation for why it is useful to maintain this distinction. There is certainly documentation value from separating programs from proofs; in practice, different concerns apply to building the two types of objects. It turns out, however, that these concerns motivate formal differences between the two universes in Coq.