(* Title: HOL/Library/Open_State_Syntax.thy Author: Florian Haftmann, TU Muenchen *)
section‹Combinator syntax for generic, open state monads (single-threaded monads)›
theory Open_State_Syntax imports Main begin
context includes state_combinator_syntax begin
subsection‹Motivation›
text‹ The logic HOL has no notion of constructor classes, so it is not possible to model monads the Haskell way in full genericity in Isabelle/HOL. However, this theory provides substantial support for a very common class of monads: \emph{state monads} (or \emph{single-threaded monads}, since a state is transformed single-threadedly). To enter from the Haskell world, 🪙‹https://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm›makes a good motivating start. Here we just sketch briefly how those monads enter the game of Isabelle/HOL. ›
subsection‹State transformations and combinators›
text‹ We classify functions operating on states into two categories: \begin{description} \item[transformations] with type signature ‹σ ==> σ'›, transforming a state. \item[``yielding'' transformations] with type signature ‹σ ==> α × σ'›, state. \item[queries] with type signature ‹σ ==> α›, computing a result dependent on a state. \end{description} By convention we write ‹σ›for types representing states and ‹α›,‹β›, ‹γ›, ‹…› for types representing side results. Type changes due to transformations are not excluded in our scenario. We aim to assert that values of any state type ‹σ›are used in a single-threaded way: after application of a transformation on a value of type ‹σ›, the former value should not be used again. To achieve this, we use a set of monad combinators: ›
text‹ Given two transformations 🍋‹f›and 🍋‹g›, they may be directly composed using the 🍋‹(∘>)›combinator, forming a forward composition: 🍋‹(f ∘> g) s = f (g s)›. After any yielding transformation, we bind the side result immediately using a lambda abstraction. This is the purpose of the 🍋‹(∘→)›combinator: 🍋‹(f ∘→ (λx. g)) s = (let (x, s') = f s in g s')›. For queries, the existing 🍋‹Let›is appropriate. Naturally, a computation may yield a side result by pairing it to the state from the left; we introduce the suggestive abbreviation 🍋‹return›for this purpose. The most crucial distinction to Haskell is that we do not need to introduce distinguished type constructors for different kinds of state. This has two consequences: \begin{itemize} \item The monad model does not state anything about the kind of state; the model for the state is completely orthogonal and may be specified completely independently. \item There is no distinguished type constructor encapsulating away the state transformation, i.e.~transformations may be applied directly without using any lifting or providing and dropping units (``open monad''). \item The type of states may change due to a transformation. \end{itemize} ›
subsection‹Monad laws›
text‹ The common monadic laws hold and may also be used as normalization rules for monadic expressions: ›
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.