author | wenzelm |
Sun, 18 Oct 2015 22:57:09 +0200 | |
changeset 61477 | e467ae7aa808 |
parent 61458 | 987533262fc2 |
child 61493 | 0debd22f0c0e |
permissions | -rw-r--r-- |
57344 | 1 |
(*:wrap=hard:maxLineLen=78:*) |
2 |
||
30124 | 3 |
theory Syntax |
4 |
imports Base |
|
5 |
begin |
|
6 |
||
58618 | 7 |
chapter \<open>Concrete syntax and type-checking\<close> |
30124 | 8 |
|
58618 | 9 |
text \<open>Pure @{text "\<lambda>"}-calculus as introduced in \chref{ch:logic} is |
45258 | 10 |
an adequate foundation for logical languages --- in the tradition of |
61477 | 11 |
\<^emph>\<open>higher-order abstract syntax\<close> --- but end-users require |
45258 | 12 |
additional means for reading and printing of terms and types. This |
61477 | 13 |
important add-on outside the logical core is called \<^emph>\<open>inner |
14 |
syntax\<close> in Isabelle jargon, as opposed to the \<^emph>\<open>outer syntax\<close> of |
|
58555 | 15 |
the theory and proof language @{cite "isabelle-isar-ref"}. |
45258 | 16 |
|
58555 | 17 |
For example, according to @{cite church40} quantifiers are represented as |
57496 | 18 |
higher-order constants @{text "All :: ('a \<Rightarrow> bool) \<Rightarrow> bool"} such that @{text |
19 |
"All (\<lambda>x::'a. B x)"} faithfully represents the idea that is displayed in |
|
20 |
Isabelle as @{text "\<forall>x::'a. B x"} via @{keyword "binder"} notation. |
|
58555 | 21 |
Moreover, type-inference in the style of Hindley-Milner @{cite hindleymilner} |
57496 | 22 |
(and extensions) enables users to write @{text "\<forall>x. B x"} concisely, when |
23 |
the type @{text "'a"} is already clear from the |
|
24 |
context.\footnote{Type-inference taken to the extreme can easily confuse |
|
25 |
users. Beginners often stumble over unexpectedly general types inferred by |
|
26 |
the system.} |
|
45258 | 27 |
|
61416 | 28 |
\<^medskip> |
61477 | 29 |
The main inner syntax operations are \<^emph>\<open>read\<close> for |
30 |
parsing together with type-checking, and \<^emph>\<open>pretty\<close> for formatted |
|
45258 | 31 |
output. See also \secref{sec:read-print}. |
32 |
||
33 |
Furthermore, the input and output syntax layers are sub-divided into |
|
61477 | 34 |
separate phases for \<^emph>\<open>concrete syntax\<close> versus \<^emph>\<open>abstract |
35 |
syntax\<close>, see also \secref{sec:parse-unparse} and |
|
45258 | 36 |
\secref{sec:term-check}, respectively. This results in the |
37 |
following decomposition of the main operations: |
|
38 |
||
61416 | 39 |
\<^item> @{text "read = parse; check"} |
45258 | 40 |
|
61416 | 41 |
\<^item> @{text "pretty = uncheck; unparse"} |
45258 | 42 |
|
43 |
||
57496 | 44 |
For example, some specification package might thus intercept syntax |
45 |
processing at a well-defined stage after @{text "parse"}, to a augment the |
|
46 |
resulting pre-term before full type-reconstruction is performed by @{text |
|
47 |
"check"}. Note that the formal status of bound variables, versus free |
|
48 |
variables, versus constants must not be changed between these phases. |
|
57345 | 49 |
|
61416 | 50 |
\<^medskip> |
51 |
In general, @{text check} and @{text uncheck} operate |
|
57345 | 52 |
simultaneously on a list of terms. This is particular important for |
53 |
type-checking, to reconstruct types for several terms of the same context |
|
54 |
and scope. In contrast, @{text parse} and @{text unparse} operate separately |
|
57496 | 55 |
on single terms. |
57345 | 56 |
|
57 |
There are analogous operations to read and print types, with the same |
|
58 |
sub-division into phases. |
|
58618 | 59 |
\<close> |
45258 | 60 |
|
30272 | 61 |
|
58618 | 62 |
section \<open>Reading and pretty printing \label{sec:read-print}\<close> |
34924 | 63 |
|
58618 | 64 |
text \<open> |
57496 | 65 |
Read and print operations are roughly dual to each other, such that for the |
66 |
user @{text "s' = pretty (read s)"} looks similar to the original source |
|
67 |
text @{text "s"}, but the details depend on many side-conditions. There are |
|
68 |
also explicit options to control the removal of type information in the |
|
69 |
output. The default configuration routinely looses information, so @{text |
|
70 |
"t' = read (pretty t)"} might fail, or produce a differently typed term, or |
|
71 |
a completely different term in the face of syntactic overloading. |
|
58618 | 72 |
\<close> |
34924 | 73 |
|
58618 | 74 |
text %mlref \<open> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
75 |
\begin{mldecls} |
57345 | 76 |
@{index_ML Syntax.read_typs: "Proof.context -> string list -> typ list"} \\ |
77 |
@{index_ML Syntax.read_terms: "Proof.context -> string list -> term list"} \\ |
|
78 |
@{index_ML Syntax.read_props: "Proof.context -> string list -> term list"} \\[0.5ex] |
|
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
79 |
@{index_ML Syntax.read_typ: "Proof.context -> string -> typ"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
80 |
@{index_ML Syntax.read_term: "Proof.context -> string -> term"} \\ |
57345 | 81 |
@{index_ML Syntax.read_prop: "Proof.context -> string -> term"} \\[0.5ex] |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
82 |
@{index_ML Syntax.pretty_typ: "Proof.context -> typ -> Pretty.T"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
83 |
@{index_ML Syntax.pretty_term: "Proof.context -> term -> Pretty.T"} \\ |
57345 | 84 |
@{index_ML Syntax.string_of_typ: "Proof.context -> typ -> string"} \\ |
85 |
@{index_ML Syntax.string_of_term: "Proof.context -> term -> string"} \\ |
|
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
86 |
\end{mldecls} |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
87 |
|
61439 | 88 |
\<^descr> @{ML Syntax.read_typs}~@{text "ctxt strs"} parses and checks a |
57345 | 89 |
simultaneous list of source strings as types of the logic. |
90 |
||
61439 | 91 |
\<^descr> @{ML Syntax.read_terms}~@{text "ctxt strs"} parses and checks a |
57345 | 92 |
simultaneous list of source strings as terms of the logic. |
57346 | 93 |
Type-reconstruction puts all parsed terms into the same scope: types of |
94 |
free variables ultimately need to coincide. |
|
57345 | 95 |
|
96 |
If particular type-constraints are required for some of the arguments, the |
|
57346 | 97 |
read operations needs to be split into its parse and check phases. Then it |
57496 | 98 |
is possible to use @{ML Type.constraint} on the intermediate pre-terms |
57846 | 99 |
(\secref{sec:term-check}). |
57345 | 100 |
|
61439 | 101 |
\<^descr> @{ML Syntax.read_props}~@{text "ctxt strs"} parses and checks a |
57346 | 102 |
simultaneous list of source strings as terms of the logic, with an implicit |
103 |
type-constraint for each argument to enforce type @{typ prop}; this also |
|
57496 | 104 |
affects the inner syntax for parsing. The remaining type-reconstruction |
105 |
works as for @{ML Syntax.read_terms}. |
|
57345 | 106 |
|
61439 | 107 |
\<^descr> @{ML Syntax.read_typ}, @{ML Syntax.read_term}, @{ML Syntax.read_prop} |
57496 | 108 |
are like the simultaneous versions, but operate on a single argument only. |
109 |
This convenient shorthand is adequate in situations where a single item in |
|
110 |
its own scope is processed. Do not use @{ML "map o Syntax.read_term"} where |
|
111 |
@{ML Syntax.read_terms} is actually intended! |
|
57345 | 112 |
|
61439 | 113 |
\<^descr> @{ML Syntax.pretty_typ}~@{text "ctxt T"} and @{ML |
57345 | 114 |
Syntax.pretty_term}~@{text "ctxt t"} uncheck and pretty-print the given type |
115 |
or term, respectively. Although the uncheck phase acts on a simultaneous |
|
57496 | 116 |
list as well, this is rarely used in practice, so only the singleton case is |
117 |
provided as combined pretty operation. There is no distinction of term vs.\ |
|
118 |
proposition. |
|
57345 | 119 |
|
61439 | 120 |
\<^descr> @{ML Syntax.string_of_typ} and @{ML Syntax.string_of_term} are |
57345 | 121 |
convenient compositions of @{ML Syntax.pretty_typ} and @{ML |
122 |
Syntax.pretty_term} with @{ML Pretty.string_of} for output. The result may |
|
123 |
be concatenated with other strings, as long as there is no further |
|
124 |
formatting and line-breaking involved. |
|
125 |
||
126 |
||
57346 | 127 |
@{ML Syntax.read_term}, @{ML Syntax.read_prop}, and @{ML |
128 |
Syntax.string_of_term} are the most important operations in practice. |
|
57345 | 129 |
|
61416 | 130 |
\<^medskip> |
131 |
Note that the string values that are passed in and out are |
|
57346 | 132 |
annotated by the system, to carry further markup that is relevant for the |
58555 | 133 |
Prover IDE @{cite "isabelle-jedit"}. User code should neither compose its |
134 |
own input strings, nor try to analyze the output strings. Conceptually this |
|
135 |
is an abstract datatype, encoded as concrete string for historical reasons. |
|
57345 | 136 |
|
137 |
The standard way to provide the required position markup for input works via |
|
138 |
the outer syntax parser wrapper @{ML Parse.inner_syntax}, which is already |
|
139 |
part of @{ML Parse.typ}, @{ML Parse.term}, @{ML Parse.prop}. So a string |
|
140 |
obtained from one of the latter may be directly passed to the corresponding |
|
57346 | 141 |
read operation: this yields PIDE markup of the input and precise positions |
142 |
for warning and error messages. |
|
58618 | 143 |
\<close> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
144 |
|
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
145 |
|
58618 | 146 |
section \<open>Parsing and unparsing \label{sec:parse-unparse}\<close> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
147 |
|
58618 | 148 |
text \<open> |
57496 | 149 |
Parsing and unparsing converts between actual source text and a certain |
61477 | 150 |
\<^emph>\<open>pre-term\<close> format, where all bindings and scopes are already resolved |
57496 | 151 |
faithfully. Thus the names of free variables or constants are determined in |
152 |
the sense of the logical context, but type information might be still |
|
61477 | 153 |
missing. Pre-terms support an explicit language of \<^emph>\<open>type constraints\<close> |
154 |
that may be augmented by user code to guide the later \<^emph>\<open>check\<close> phase. |
|
45258 | 155 |
|
57496 | 156 |
Actual parsing is based on traditional lexical analysis and Earley parsing |
157 |
for arbitrary context-free grammars. The user can specify the grammar |
|
61477 | 158 |
declaratively via mixfix annotations. Moreover, there are \<^emph>\<open>syntax |
159 |
translations\<close> that can be augmented by the user, either declaratively via |
|
57496 | 160 |
@{command translations} or programmatically via @{command |
58555 | 161 |
parse_translation}, @{command print_translation} @{cite |
162 |
"isabelle-isar-ref"}. The final scope-resolution is performed by the system, |
|
163 |
according to name spaces for types, term variables and constants determined |
|
164 |
by the context. |
|
58618 | 165 |
\<close> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
166 |
|
58618 | 167 |
text %mlref \<open> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
168 |
\begin{mldecls} |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
169 |
@{index_ML Syntax.parse_typ: "Proof.context -> string -> typ"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
170 |
@{index_ML Syntax.parse_term: "Proof.context -> string -> term"} \\ |
57496 | 171 |
@{index_ML Syntax.parse_prop: "Proof.context -> string -> term"} \\[0.5ex] |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
172 |
@{index_ML Syntax.unparse_typ: "Proof.context -> typ -> Pretty.T"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
173 |
@{index_ML Syntax.unparse_term: "Proof.context -> term -> Pretty.T"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
174 |
\end{mldecls} |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
175 |
|
61439 | 176 |
\<^descr> @{ML Syntax.parse_typ}~@{text "ctxt str"} parses a source string as |
57346 | 177 |
pre-type that is ready to be used with subsequent check operations. |
178 |
||
61439 | 179 |
\<^descr> @{ML Syntax.parse_term}~@{text "ctxt str"} parses a source string as |
57346 | 180 |
pre-term that is ready to be used with subsequent check operations. |
181 |
||
61439 | 182 |
\<^descr> @{ML Syntax.parse_prop}~@{text "ctxt str"} parses a source string as |
57346 | 183 |
pre-term that is ready to be used with subsequent check operations. The |
184 |
inner syntax category is @{typ prop} and a suitable type-constraint is |
|
57496 | 185 |
included to ensure that this information is observed in subsequent type |
186 |
reconstruction. |
|
57346 | 187 |
|
61439 | 188 |
\<^descr> @{ML Syntax.unparse_typ}~@{text "ctxt T"} unparses a type after |
57346 | 189 |
uncheck operations, to turn it into a pretty tree. |
190 |
||
61439 | 191 |
\<^descr> @{ML Syntax.unparse_term}~@{text "ctxt T"} unparses a term after |
57346 | 192 |
uncheck operations, to turn it into a pretty tree. There is no distinction |
193 |
for propositions here. |
|
194 |
||
195 |
||
57496 | 196 |
These operations always operate on a single item; use the combinator @{ML |
197 |
map} to apply them to a list. |
|
58618 | 198 |
\<close> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
199 |
|
39852 | 200 |
|
58618 | 201 |
section \<open>Checking and unchecking \label{sec:term-check}\<close> |
34924 | 202 |
|
58618 | 203 |
text \<open>These operations define the transition from pre-terms and |
45258 | 204 |
fully-annotated terms in the sense of the logical core |
205 |
(\chref{ch:logic}). |
|
206 |
||
61477 | 207 |
The \<^emph>\<open>check\<close> phase is meant to subsume a variety of mechanisms |
45258 | 208 |
in the manner of ``type-inference'' or ``type-reconstruction'' or |
209 |
``type-improvement'', not just type-checking in the narrow sense. |
|
61477 | 210 |
The \<^emph>\<open>uncheck\<close> phase is roughly dual, it prunes type-information |
45258 | 211 |
before pretty printing. |
212 |
||
213 |
A typical add-on for the check/uncheck syntax layer is the @{command |
|
58555 | 214 |
abbreviation} mechanism @{cite "isabelle-isar-ref"}. Here the user specifies |
57496 | 215 |
syntactic definitions that are managed by the system as polymorphic @{text |
216 |
"let"} bindings. These are expanded during the @{text "check"} phase, and |
|
217 |
contracted during the @{text "uncheck"} phase, without affecting the |
|
218 |
type-assignment of the given terms. |
|
45258 | 219 |
|
61416 | 220 |
\<^medskip> |
221 |
The precise meaning of type checking depends on the context --- |
|
57496 | 222 |
additional check/uncheck modules might be defined in user space. |
45258 | 223 |
|
224 |
For example, the @{command class} command defines a context where |
|
225 |
@{text "check"} treats certain type instances of overloaded |
|
226 |
constants according to the ``dictionary construction'' of its |
|
227 |
logical foundation. This involves ``type improvement'' |
|
228 |
(specialization of slightly too general types) and replacement by |
|
58555 | 229 |
certain locale parameters. See also @{cite "Haftmann-Wenzel:2009"}. |
58618 | 230 |
\<close> |
39852 | 231 |
|
58618 | 232 |
text %mlref \<open> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
233 |
\begin{mldecls} |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
234 |
@{index_ML Syntax.check_typs: "Proof.context -> typ list -> typ list"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
235 |
@{index_ML Syntax.check_terms: "Proof.context -> term list -> term list"} \\ |
57496 | 236 |
@{index_ML Syntax.check_props: "Proof.context -> term list -> term list"} \\[0.5ex] |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
237 |
@{index_ML Syntax.uncheck_typs: "Proof.context -> typ list -> typ list"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
238 |
@{index_ML Syntax.uncheck_terms: "Proof.context -> term list -> term list"} \\ |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
239 |
\end{mldecls} |
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
240 |
|
61439 | 241 |
\<^descr> @{ML Syntax.check_typs}~@{text "ctxt Ts"} checks a simultaneous list |
57346 | 242 |
of pre-types as types of the logic. Typically, this involves normalization |
243 |
of type synonyms. |
|
244 |
||
61439 | 245 |
\<^descr> @{ML Syntax.check_terms}~@{text "ctxt ts"} checks a simultaneous list |
57346 | 246 |
of pre-terms as terms of the logic. Typically, this involves type-inference |
247 |
and normalization term abbreviations. The types within the given terms are |
|
248 |
treated in the same way as for @{ML Syntax.check_typs}. |
|
249 |
||
250 |
Applications sometimes need to check several types and terms together. The |
|
251 |
standard approach uses @{ML Logic.mk_type} to embed the language of types |
|
252 |
into that of terms; all arguments are appended into one list of terms that |
|
57496 | 253 |
is checked; afterwards the type arguments are recovered with @{ML |
57346 | 254 |
Logic.dest_type}. |
255 |
||
61439 | 256 |
\<^descr> @{ML Syntax.check_props}~@{text "ctxt ts"} checks a simultaneous list |
57346 | 257 |
of pre-terms as terms of the logic, such that all terms are constrained by |
258 |
type @{typ prop}. The remaining check operation works as @{ML |
|
259 |
Syntax.check_terms} above. |
|
260 |
||
61439 | 261 |
\<^descr> @{ML Syntax.uncheck_typs}~@{text "ctxt Ts"} unchecks a simultaneous |
57346 | 262 |
list of types of the logic, in preparation of pretty printing. |
263 |
||
61439 | 264 |
\<^descr> @{ML Syntax.uncheck_terms}~@{text "ctxt ts"} unchecks a simultaneous |
57346 | 265 |
list of terms of the logic, in preparation of pretty printing. There is no |
266 |
distinction for propositions here. |
|
267 |
||
268 |
||
57496 | 269 |
These operations always operate simultaneously on a list; use the combinator |
270 |
@{ML singleton} to apply them to a single item. |
|
58618 | 271 |
\<close> |
39876
1ff9bce085bd
preliminary material on "Concrete syntax and type-checking";
wenzelm
parents:
39865
diff
changeset
|
272 |
|
30124 | 273 |
end |