Quelle  Syntax.thy

(*:maxLineLen=78:*)

theory Syntax
imports Base
begin

chapter ‹Concrete syntax and type-checking›

text ‹
  Pure ‹λ›-c
  foundation for logical languages --- in the tradition of 🪙‹higher-order
  abstract syntax›
  printing of terms and types. This important add-on outside the logical core
  is called 🪙‹inner syntax› in Isabelle jargon, as opposed to the 🪙‹outer
  syntax›

  For example, according to 🍋‹church40› quantifiers are represented as
  higher-order constants ‹All :: ('a ==> bool) ==> bool› such that ‹All (λx::'a. B
  x)›
  B x› via @{keyword "binder"} notation. Moreover, type-inference in the style
  of Hindley-Milner 🍋‹hindleymilner› (and extensions) enables users to
  write ‹∀x. B x› concisely, when the type ‹'a› is already clear from the
  context.🪙‹Type-inference taken to the extreme can easily confuse users.
  Beginners often stumble over unexpectedly general types inferred by the
  system.›

  🪙
  The main inner syntax operations are 🪙‹read› for parsing together with
  type-checking, and 🪙‹pretty› for formatted output. See also
  \secref{sec:read-print}.

  Furthermore, the input and output syntax layers are sub-divided into
  separate phases for 🪙‹concrete syntax› versus 🪙‹abstract syntax›, see also
  \secref{sec:parse-unparse} and \secref{sec:term-check}, respectively. This
  results in the following decomposition of the main operations:

    🪙 ‹read = parse; check›

    🪙 ‹pretty = uncheck; unparse›

  For example, some specification package might thus intercept syntax
  processing at a well-defined stage after ‹parse›, to a augment the resulting
  pre-term before full type-reconstruction is performed by ‹check›. Note that
  the formal status of bound variables, versus free variables, versus
  constants must not be changed between these phases.

  🪙
  In general, ‹check› and ‹uncheck› operate simultaneously on a list of terms.
  This is particular important for type-checking, to reconstruct types for
  several terms of the same context and scope. In contrast, ‹parse› and
  ‹unparse› operate separately on single terms.

  There are analogous operations to read and print types, with the same
  sub-division into phases.
›


section ‹Reading and pretty printing \label{sec:read-print}›

text ‹
  Read and print operations are roughly dual to each other, such that for the
  user ‹s' = pretty (read s)› l
  but the details depend on many side-conditions. There are also explicit
  options to control the removal of type information in the output. The
  default configuration routinely looses information, so ‹t' = read (pretty
  t)›
  different term in the face of syntactic overloading.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Syntax.read_typs: "Proof.context -> string list -> typ list"} \\
  @{define_ML Syntax.read_terms: "Proof.context -> string list -> term list"} \\
  @{define_ML Syntax.read_props: "Proof.context -> string list -> term list"} \\[0.5ex]
  @{define_ML Syntax.read_typ: "Proof.context -> string -> typ"} \\
  @{define_ML Syntax.read_term: "Proof.context -> string -> term"} \\
  @{define_ML Syntax.read_prop: "Proof.context -> string -> term"} \\[0.5ex]
  @{define_ML Syntax.pretty_typ: "Proof.context -> typ -> Pretty.T"} \\
  @{define_ML Syntax.pretty_term: "Proof.context -> term -> Pretty.T"} \\
  @{define_ML Syntax.string_of_typ: "Proof.context -> typ -> string"} \\
  @{define_ML Syntax.string_of_term: "Proof.context -> term -> string"} \\
  \end{mldecls}
 
  🪙 🪙‹Syntax.read_typs›~\
  of source strings as types of the logic.

  🪙 🪙‹Syntax.read_terms›~‹ctxt strs› parses and checks a simultaneous list
  of source strings as terms of the logic. Type-reconstruction puts all parsed
  terms into the same scope: types of free variables ultimately need to
  coincide.

  If particular type-constraints are required for some of the arguments, the
  read operations needs to be split into its parse and check phases. Then it
  is possible to use 🪙‹Type.constraint› on the intermediate pre-terms
  (\secref{sec:term-check}).

  🪙 🪙‹Syntax.read_props›~‹ctxt strs› parses and checks a simultaneous list
  of source strings as terms of the logic, with an implicit type-constraint
  for each argument to enforce type 🍋‹prop›; this also affects the inner
  syntax for parsing. The remaining type-reconstruction works as for 🪙‹Syntax.read_terms›.

  🪙 🪙‹Syntax.read_typ›, 🪙‹Syntax.read_term›, 🪙‹Syntax.read_prop› are
  like the simultaneous versions, but operate on a single argument only. This
  convenient shorthand is adequate in situations where a single item in its
  own scope is processed. Do not use 🪙‹map o Syntax.read_term› where 🪙‹Syntax.read_terms› is actually intended!

  🪙 🪙‹Syntax.pretty_typ›~‹ctxt T› and 🪙‹Syntax.pretty_term›~‹ctxt t›
  uncheck and pretty-print the given type or term, respectively. Although the
  uncheck phase acts on a simultaneous list as well, this is rarely used in
  practice, so only the singleton case is provided as combined pretty
  operation. There is no distinction of term vs.\ proposition.

  🪙 🪙‹Syntax.string_of_typ› and 🪙‹Syntax.string_of_term› are convenient
  compositions of 🪙‹Syntax.pretty_typ› and 🪙‹Syntax.pretty_term› with
  🪙‹Pretty.string_of› for output. The result may be concatenated with other
  strings, as long as there is no further formatting and line-breaking
  involved.


  🪙‹Syntax.read_term›, 🪙‹Syntax.read_prop›, and 🪙‹Syntax.string_of_term› are the most important operations in practice.

  🪙
  Note that the string values that are passed in and out are annotated by the
  system, to carry further markup that is relevant for the Prover IDE 🍋‹"isabelle-jedit"›. User code should neither compose its own input strings,
  nor try to analyze the output strings. Conceptually this is an abstract
  datatype, encoded as concrete string for historical reasons.

  The standard way to provide the required position markup for input works via
  the outer syntax parser wrapper 🪙‹Parse.inner_syntax›, which is already
  part of 🪙‹Parse.typ›, 🪙‹Parse.term›, 🪙‹Parse.prop›. So a string
  obtained from one of the latter may be directly passed to the corresponding
  read operation: this yields PIDE markup of the input and precise positions
  for warning and error messages.
›


section ‹Parsing and unparsing \label{sec:parse-unparse}›

text ‹
  Parsing and unparsing converts between actual source text and a certain
  🪙‹pre-term› f
  faithfully. Thus the names of free variables or constants are determined in
  the sense of the logical context, but type information might be still
  missing. Pre-terms support an explicit language of 🪙‹type constraints› that
  may be augmented by user code to guide the later 🪙‹check› phase.

  Actual parsing is based on traditional lexical analysis and Earley parsing
  for arbitrary context-free grammars. The user can specify the grammar
  declaratively via mixfix annotations. Moreover, there are 🪙‹syntax
  translations›
  @{command translations} or programmatically via @{command
  parse_translation}, @{command print_translation} 🍋‹"isabelle-isar-ref"›. The final scope-resolution is performed by the system,
  according to name spaces for types, term variables and constants determined
  by the context.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Syntax.parse_typ: "Proof.context -> string -> typ"} \\
  @{define_ML Syntax.parse_term: "Proof.context -> string -> term"} \\
  @{define_ML Syntax.parse_prop: "Proof.context -> string -> term"} \\[0.5ex]
  @{define_ML Syntax.unparse_typ: "Proof.context -> typ -> Pretty.T"} \\
  @{define_ML Syntax.unparse_term: "Proof.context -> term -> Pretty.T"} \\
  \end{mldecls}
 
  🪙 🪙‹Syntax.parse_typ›~\
  is ready to be used with subsequent check operations.

  🪙 🪙‹Syntax.parse_term›~‹ctxt str› parses a source string as pre-term that
  is ready to be used with subsequent check operations.

  🪙 🪙‹Syntax.parse_prop›~‹ctxt str› parses a source string as pre-term that
  is ready to be used with subsequent check operations. The inner syntax
  category is 🍋‹prop› and a suitable type-constraint is included to ensure
  that this information is observed in subsequent type reconstruction.

  🪙 🪙‹Syntax.unparse_typ›~‹ctxt T› unparses a type after uncheck
  operations, to turn it into a pretty tree.

  🪙 🪙‹Syntax.unparse_term›~‹ctxt T› unparses a term after uncheck
  operations, to turn it into a pretty tree. There is no distinction for
  propositions here.


  These operations always operate on a single item; use the combinator 🪙‹map› to apply them to a list.
›


section ‹Checking and unchecking \label{sec:term-check}›

text ‹
  These operations define the transition from pre-terms and fully-annotated
  terms in the sense of the logical core (\chref{ch:logic}).
 
  The 🪙‹check› p
  of ``type-inference'' or ``type-reconstruction'' or ``type-improvement'',
  not just type-checking in the narrow sense. The 🪙‹uncheck› phase is roughly
  dual, it prunes type-information before pretty printing.

  A typical add-on for the check/uncheck syntax layer is the @{command
  abbreviation} mechanism 🍋‹"isabelle-isar-ref"›. Here the user specifies
  syntactic definitions that are managed by the system as polymorphic ‹let›
  bindings. These are expanded during the ‹check› phase, and contracted during
  the ‹uncheck› phase, without affecting the type-assignment of the given
  terms.

  🪙
  The precise meaning of type checking depends on the context --- additional
  check/uncheck modules might be defined in user space.

  For example, the @{command class} command defines a context where ‹check›
  treats certain type instances of overloaded constants according to the
  ``dictionary construction'' of its logical foundation. This involves ``type
  improvement'' (specialization of slightly too general types) and replacement
  by certain locale parameters. See also 🍋‹"Haftmann-Wenzel:2009"›.
›

text %mlref ‹
  \begin{mldecls}
  @{define_ML Syntax.check_typs: "Proof.context -> typ list -> typ list"} \\
  @{define_ML Syntax.check_terms: "Proof.context -> term list -> term list"} \\
  @{define_ML Syntax.check_props: "Proof.context -> term list -> term list"} \\[0.5ex]
  @{define_ML Syntax.uncheck_typs: "Proof.context -> typ list -> typ list"} \\
  @{define_ML Syntax.uncheck_terms: "Proof.context -> term list -> term list"} \\
  \end{mldecls}
 
  🪙 🪙‹Syntax.check_typs›~\
  as types of the logic. Typically, this involves normalization of type
  synonyms.

  🪙 🪙‹Syntax.check_terms›~‹ctxt ts› checks a simultaneous list of pre-terms
  as terms of the logic. Typically, this involves type-inference and
  normalization term abbreviations. The types within the given terms are
  treated in the same way as for 🪙‹Syntax.check_typs›.

  Applications sometimes need to check several types and terms together. The
  standard approach uses 🪙‹Logic.mk_type› to embed the language of types
  into that of terms; all arguments are appended into one list of terms that
  is checked; afterwards the type arguments are recovered with 🪙‹Logic.dest_type›.

  🪙 🪙‹Syntax.check_props›~‹ctxt ts› checks a simultaneous list of pre-terms
  as terms of the logic, such that all terms are constrained by type 🍋‹prop›. The remaining check operation works as 🪙‹Syntax.check_terms›
  above.

  🪙 🪙‹Syntax.uncheck_typs›~‹ctxt Ts› unchecks a simultaneous list of types
  of the logic, in preparation of pretty printing.

  🪙 🪙‹Syntax.uncheck_terms›~‹ctxt ts› unchecks a simultaneous list of terms
  of the logic, in preparation of pretty printing. There is no distinction for
  propositions here.


  These operations always operate simultaneously on a list; use the combinator
  🪙‹singleton› to apply them to a single item.
›

end