diff -r 419116f1157a -r e23770bc97c8 doc-src/AxClass/Group/Product.thy --- a/doc-src/AxClass/Group/Product.thy Thu Feb 26 08:44:44 2009 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ - -header {* Syntactic classes *} - -theory Product imports Main begin - -text {* - \medskip\noindent There is still a feature of Isabelle's type system - left that we have not yet discussed. When declaring polymorphic - constants @{text "c \ \"}, the type variables occurring in @{text \} - may be constrained by type classes (or even general sorts) in an - arbitrary way. Note that by default, in Isabelle/HOL the - declaration @{text "\ \ 'a \ 'a \ 'a"} is actually an abbreviation - for @{text "\ \ 'a\type \ 'a \ 'a"} Since class @{text type} is the - universal class of HOL, this is not really a constraint at all. - - The @{text product} class below provides a less degenerate example of - syntactic type classes. -*} - -axclass - product \ type -consts - product :: "'a\product \ 'a \ 'a" (infixl "\" 70) - -text {* - Here class @{text product} is defined as subclass of @{text type} - without any additional axioms. This effects in logical equivalence - of @{text product} and @{text type}, as is reflected by the trivial - introduction rule generated for this definition. - - \medskip So what is the difference of declaring @{text "\ \ - 'a\product \ 'a \ 'a"} vs.\ declaring @{text "\ \ 'a\type \ 'a \ - 'a"} anyway? In this particular case where @{text "product \ - type"}, it should be obvious that both declarations are the same - from the logic's point of view. It even makes the most sense to - remove sort constraints from constant declarations, as far as the - purely logical meaning is concerned \cite{Wenzel:1997:TPHOL}. - - On the other hand there are syntactic differences, of course. - Constants @{text \} on some type @{text \} are rejected by the - type-checker, unless the arity @{text "\ \ product"} is part of the - type signature. In our example, this arity may be always added when - required by means of an \isakeyword{instance} with the default proof - (double-dot). - - \medskip Thus, we may observe the following discipline of using - syntactic classes. Overloaded polymorphic constants have their type - arguments restricted to an associated (logically trivial) class - @{text c}. Only immediately before \emph{specifying} these - constants on a certain type @{text \} do we instantiate @{text "\ \ - c"}. - - This is done for class @{text product} and type @{typ bool} as - follows. -*} - -instance bool :: product .. -defs (overloaded) - product_bool_def: "x \ y \ x \ y" - -text {* - The definition @{text prod_bool_def} becomes syntactically - well-formed only after the arity @{text "bool \ product"} is made - known to the type checker. - - \medskip It is very important to see that above \isakeyword{defs} are - not directly connected with \isakeyword{instance} at all! We were - just following our convention to specify @{text \} on @{typ bool} - after having instantiated @{text "bool \ product"}. Isabelle does - not require these definitions, which is in contrast to programming - languages like Haskell \cite{haskell-report}. - - \medskip While Isabelle type classes and those of Haskell are almost - the same as far as type-checking and type inference are concerned, - there are important semantic differences. Haskell classes require - their instances to \emph{provide operations} of certain \emph{names}. - Therefore, its \texttt{instance} has a \texttt{where} part that tells - the system what these ``member functions'' should be. - - This style of \texttt{instance} would not make much sense in - Isabelle's meta-logic, because there is no internal notion of - ``providing operations'' or even ``names of functions''. -*} - -end