notebooks/Lambda Notebook Demo.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Lambda notebook demo v. 1.0.2\n",
    "\n",
    "## Author: Kyle Rawlins\n",
    "\n",
    "This notebook provides a demo of the core capabilities of the lambda notebook, aimed at linguists who already have training in semantics (but not necessarily implemented semantics).\n",
    "\n",
    "Last updated Aug 2023. Version history:\n",
    "\n",
    " * 0.5: first version\n",
    " * 0.6: updated to work with refactored class hierarchy (Apr 2013)\n",
    " * 0.6.1: small fixes to adapt to changes in various places (Sep 2013)\n",
    " * 0.7: various fixes to work with alpha release (Jan 2014)\n",
    " * 0.9: substantial updates, merge content from LSA poster (Apr 2014)\n",
    " * 0.95: substantial updates for a series of demos in Apr-May 2014\n",
    " * 1.0: various changes / fixes, more stand-alone text (2017)\n",
    " * 1.0.1: small tweaks (Nov/Dec 2018)\n",
    " * 1.0.2: bugfixes\n",
    " \n",
    "To run through this demo incrementally, use shift-enter (runs and moves to next cell).  If you run things out of order, you may encounter problems (missing variables etc.)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "from lamb.types import TypeMismatch, type_e, type_t, type_property\n",
    "from lamb.meta import TypedTerm, TypedExpr, LFun, CustomTerm"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "# There are several ways of display outputs, this one is the default:\n",
    "lamb.display.default(style=lamb.display.DerivStyle.BOXES)\n",
    "# you can also try:\n",
    "# lamb.display.default(style=lamb.display.DerivStyle.PROOF)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# First pitch\n",
    "\n",
    "Have you ever wanted to type something like this in, and have it actually do something?"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "||every|| = λ f_<e,t> : λ g_<e,t> : Forall x_e : f(x) >> g(x)\n",
    "||student|| = L x_e : Student(x)\n",
    "||danced|| = L x_e : Danced(x)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r = ((every * student) * danced)\n",
    "r"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r.tree()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Two problems in formal semantics #\n",
    "\n",
    "1. Type-driven computation could be a lot easier to visualize and check.  (Q: could it be made too easy?)\n",
    "\n",
    "2. Grammar fragments as in Montague Grammar: good idea in principle, hard to use in practice.\n",
    "\n",
    "  * A **fragment** is a *complete* formalization of *sublanguage* consisting of the *key relevant phenomena* for the problem at hand.  (Potential problem-points italicized.)\n",
    "\n",
    "Solution: a system for developing interactive fragments: \"*IPython Lambda Notebook*\"\n",
    "\n",
    "* Creator can work interactively with analysis -- accelerate development, limit time spent on tedious details.\n",
    "* Reader can explore derivations in ways that are not typically possible in typical paper format.\n",
    "* Creator and reader can be certain that derivations work, verified by the system.\n",
    "* Bring closer together formal semantics and computational modeling.\n",
    "\n",
    "Inspired by:\n",
    "\n",
    " * Von Eijck and Unger (2013): implementation of compositional semantics in Haskell.  No interface (beyond standard Haskell terminal); great if you like Haskell.  Introduced the idea of a fragment in digital form.\n",
    " * UPenn Lambda calculator (Champollion, Tauberer, and Romero 2007): teaching oriented.  (Now under development again.)\n",
    " * `nltk.sem`: implementation of the lambda calculus with a typed metalanguage, interface with theorem provers.  No interactive interface.\n",
    " * Jealousy of R studio, Matlab, Mathematica, etc.\n",
    "\n",
    "### The role of formalism & fragments ###\n",
    "\n",
    "What does *formal* mean in semantics?  What properties should a theory have?\n",
    "\n",
    " 1. Mathematically precise (lambda calculus, type theory, logic, model theory(?), ...)\n",
    " 2. Complete (covers \"all\" the relevant data).\n",
    " 3. Predictive (like any scientific theory).\n",
    " 4. Consistent, or at least compatible (with itself, analyses of other phenomena, some unifying conception of the grammar).\n",
    " \n",
    "The *method of fragments* (Partee 1979, Partee and Hendriks 1997) provides a structure for meeting these criteria.\n",
    "\n",
    " * Paper with a fragment provides a working system.  (Probably.)\n",
    " * Explicit outer bound for empirical coverage.\n",
    " * Integration with a particular theory of grammar.  (To some extent.)\n",
    " * Explicit answer to many detailed questions not necessarily dealt with in the text.\n",
    " \n",
    "**Claim**: fragments are a method of replicability, similar to a computational modeller providing their model.\n",
    "\n",
    " * To be clear, a fragment is neither necessary nor sufficient for having a good theory / analysis / paper...\n",
    "\n",
    "Additional benefit: useful internal check for researcher.\n",
    "\n",
    ">\"...But I feel strongly that it is important to try to [work with fully explicit fragments] periodically, because otherwise it is extremely easy to think that you have a solution to a problem when in fact you don't.\" (Partee 1979, p. 41)\n",
    "\n",
    "### The challenges of fragments\n",
    "\n",
    "Part 1 of the above quote:\n",
    "\n",
    ">\"It can be very frustrating to try to specify frameworks and fragments explicitly; this project has not been entirely rewarding.  I would not recommend that one always work with the constraint of full explicitness.\" (Ibid.)\n",
    "\n",
    " * Fragments can be tedious and time-consuming to write (not to mention hard).\n",
    " * Fragments as traditionally written are in practice not easy for a reader to use.\n",
    " \n",
    "   - Dense/unapproachable.  With exactness can come a huge chunk of hard-to-digest formalism.  E.g. Partee (1979), about 10% of the paper.\n",
    "   - Monolithic/non-modular.  For the specified sublanguage, everything specified.  Outside the bounds of the sublanguage, nothing specified.  How does the theory fit in with others?\n",
    "   - Exact opposite of the modern method -- researchers typically hold most aspects of the grammar constant (implicitly) while changing a few key points.  (*Portner and Partee intro*)\n",
    "\n",
    "**Summary:** In practice, the typical payoff for neither the reader nor the writer of a fragment exceeded the effort.\n"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# A solution: digital fragments\n",
    "\n",
    "Von Eijck and Unger 2010: specify a fragment in digital form.\n",
    "\n",
    "* They use Haskell.  Type system of Haskell extremely well-suited to natural language semantics.\n",
    "* (Provocative statement) Interface, learning curve of Haskell not well suited to semanticists (or most people)?\n",
    "\n",
    "### Benefits of digital fragments (in principle)\n",
    "\n",
    "* Interactive.\n",
    "* Easy to distribute, adapt, modify.\n",
    "* Possibility of modularity.  (E.g. abstract a 'library' for compositional systems away from the analysis of a particular phenomenon.)\n",
    "* Bring closer together the CogSci idea of a 'computational model' to the project of natural language semantics.\n",
    "* Connections to computational semantics. (weak..)\n",
    "\n",
    "### What sorts of things might we want in a fragment / system for fragments?\n",
    "\n",
    "* Typed lambda calculus.\n",
    "* Logic / logical metalanguage.\n",
    "* Framework for semantic composition.  (Broad...)\n",
    "* Model theory? (x)\n",
    "* Interface with theorem provers? (x)\n",
    "\n",
    "IPython Lambda Notebook aims to provide these tools in a usable, interactive, format.\n",
    "\n",
    "* Choose Python, rather than Haskell/Java.  Easy learning curve, rapid prototyping, existence of IPython.\n",
    "\n",
    "**Layer 1**: interface using IPython Notebook.\n",
    "\n",
    "**Layer 2**: flexible typed metalanguage.\n",
    "\n",
    "**Layer 3**: composition system for object language, building on layer 2."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Layer 1: an interface using IPython/Jupyter Notebook (Perez and Granger 2007) ##\n",
    "\n",
    " * Client-server system where a specialized IPython \"kernel\" is running in the background. This kernel implements various tools for formal semantics (see parts 2-3).\n",
    " * Page broken down into cells in which can be entered python code, markdown code, raw text, other formats.\n",
    " * Jupyter: supports display of graphical representations of python objects.\n",
    " * Notebook format uses the \"MathJax\" framework to enable it to render most math-mode latex.  Can have python objects automatically generate decent-looking formulas.  Can use latex math mode in documentation as well (e.g. $\\lambda x \\in D_e : \\mathit{CAT}(x)$)\n",
    "\n",
    "This all basically worked off-the-shelf.\n",
    "\n",
    "* Bulk of interface work so far: rendering code for logical and compositional representations.\n",
    "* Future: interactive widgets, etc."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "pmw_test1 = %te L p_t : L x_e : P_<e,t>(x) & p\n",
    "pmw_test1"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "pmw_test1._repr_latex_()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "&nbsp;\n",
    "\n",
    "## Part 2: a typed metalanguage ##"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The **metalanguage** infrastructure is a set of classes that implement the building blocks of logical expressions, lambda terms, and various combinations combinations. This rests on an implementation of a **type system** that matches what semanticists tend to assume.\n",
    "\n",
    "Starting point (2012): a few implementations of things like predicate logic do exist, this is an intro AI exercise sometimes.  I started with the [AIMA python](http://code.google.com/p/aima-python/) _Expr_ class, based on the standard Russell and Norvig AI text.  But, had to scrap most of it.  Another starting point would have been `nltk.sem` (I was unaware of its existence at the time.)\n",
    "\n",
    "Preface cell with `%%lamb` to enter metalanguage formulas directly.  The following cell defines a variable `x` that has type e, and exports it to the notebook's environment."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb reset\n",
    "x = x_e # define x to have this type"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "x.type"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This next cell defines some variables whose values are more complex object -- in fact, functions in the typed lambda calculus."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "test1 = L p_t : L x_e : P(x) & p # based on a Partee et al example\n",
    "test1b = L x_e : P(x) & Q(x)\n",
    "t2 = Q(x_e)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "These are now registered as variables in the python namespace and can be manipulated directly.  A typed lambda calculus is fully implemented with all that that entails -- e.g. the value of `test1` includes the whole syntactic structure of the formula, its type, etc. and can be used in constructing new formulas.  The following cells build a complex function-argument formula, and following that, does the reduction.\n",
    "\n",
    "(Notice that beta reduction works properly, i.e. bound $x$ in the function is renamed in order to avoid collision with the free `x` in the argument.)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "test1(t2)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "test1(t2).reduce()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "catf = L x_e: Cat(x)\n",
    "dogf = λx: Dog(x_e)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "(catf(x)).type"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "catf.type"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Type checking of course is a part of all this.  If the types don't match, the computation will throw a `TypeMismatch` exception.  The following cell uses python syntax to catch and print such errors."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "with lamb.errors():\n",
    "    display(test1(x)) # function is type <t,<e,t>> so will trigger a type mismatch."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "A more complex expression:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "p2 = (Cat_<e,t>(x_e) & p_t) >> (Exists y: Dog_<e,t>(y_e))"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "What is going on behind the scenes?  The objects manipulated are recursively structured python objects of class TypedExpr.\n",
    "\n",
    "Class _TypedExpr_: parent class for typed expressions.  Key subclasses:\n",
    "\n",
    "* BinaryOpExpr: parent class for things like conjunction.\n",
    "* TypedTerm: variables, constants of arbitrary type\n",
    "* BindingOp: operators that bind a single variable\n",
    "  * LFun: lambda expression\n",
    "\n",
    "Many straightforward expressions can be parsed.  Most expressions are created using a call to TypedExpr.factory, which is abbreviated as \"te\" in the following examples.  The `%%lamb` magic is calling this behind the scenes.\n",
    "\n",
    "Three ways of instantiating a variable `x` of type `e`:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb \n",
    "x = x_e # use cell magic"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "x = te(\"x_e\") # use factory function to parse string\n",
    "x"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "x = meta.TypedTerm(\"x\", types.type_e) # use object constructer\n",
    "x"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Various convenience python operators are overloaded, including functional calls.  Here is an example repeated from earlier in two forms:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "p2 = (Cat_<e,t>(x_e) & p_t) >> (Exists y: Dog_<e,t>(y_e))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "p2 = (te(\"Cat_<e,t>(x)\") & te(\"p_t\")) >> te(\"(Exists y: Dog_<e,t>(y_e))\")\n",
    "p2"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Let's examine in detail what happens when a function and argument combine."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "catf = meta.LFun(te(\"x_e\"), te(\"Cat(x_e)\"))\n",
    "catf"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "catf(te(\"y_e\"))"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Building a function-argument expression builds a complex, unreduced expression.  This can be explicitly reduced (note that the `reduce_all()` function would be used to apply reduction  recursively):"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "catf(te(\"y_e\")).reduce()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "(catf(te(\"y_e\")).reduce()).derivation"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The metalanguage supports some basic type inference.  Type inference happens already on combination of a function and argument into an unreduced expression, not on beta-reduction."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%lamb ttest = L x_X : P_<?,t>(x) # type <?,t>\n",
    "%lamb tvar = y_t\n",
    "ttest(tvar)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "&nbsp;\n",
    "\n",
    "## Part 3: composition systems for an object language ##\n",
    "\n",
    "On top of the metalanguage are '**composition systems**' for modeling (step-by-step) semantic composition in an object language such as English.  This is the part of the lambda notebook that tracks and manipulates mappings between object language elements (words, trees, etc) and denotations in the metalanguage.  \n",
    "\n",
    "A composition at its core consists of a set of composition rules; the following cell defines a simple composition system that will be familiar to anyone who has taken a basic course in compositional semantics.  (This example is just a redefinition of the default composition system.)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "# none of this is strictly necessary, the built-in library already provides effectively this system.\n",
    "fa = lang.BinaryCompositionOp(\"FA\", lang.fa_fun, reduce=True)\n",
    "pm = lang.BinaryCompositionOp(\"PM\", lang.pm_fun, commutative=False, reduce=True)\n",
    "pa = lang.BinaryCompositionOp(\"PA\", lang.pa_fun, allow_none=True)\n",
    "demo_hk_system = lang.CompositionSystem(name=\"demo system\", rules=[fa, pm, pa])\n",
    "lang.set_system(demo_hk_system)\n",
    "demo_hk_system"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Expressing denotations is done in a `%%lamb` cell, and almost always begins with lexical items.  The following cell defines several lexical items that will be familiar from introductory exercises in the Heim & Kratzer 1998 textbook \"Semantics in Generative Grammar\".  These definitions produce items that are subclasses of the class `Composable`."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "||cat|| = L x_e: Cat(x)\n",
    "||gray|| = L x_e: Gray(x)\n",
    "||john|| = John_e\n",
    "||julius|| = Julius_e\n",
    "||inP|| = L x_e : L y_e : In(y, x) # `in` is a reserved word in python\n",
    "||texas|| = Texas_e\n",
    "||isV|| = L p_<e,t> : p # `is` is a reserved word in python"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "In the purely type-driven mode, composition is triggered by using the '`*`' operator on a `Composable`.  This searches over the available composition operations in the system to see if any results can be had.  `inP` and `texas` above should be able to compose using the FA rule:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "inP * texas"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "On the other hand `isV` is looking for a property, so we shouldn't expect succesful composition.  Below this I have given a complete sentence and shown some introspection on that composition result."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "julius * isV # will fail due to type mismatches"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence1 = julius * (isV * (inP * texas))\n",
    "display(sentence1[0].source_tree())\n",
    "sentence1"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence1.trace()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Composition will find all possible paths (beware of combinatorial explosion).  I have temporarily disabled the fact that standard PM is symmetric/commutative (because of conjunction), to illustrate a case with multiple composition paths:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "gray * cat"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "gray * (cat * (inP * texas))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "a = lang.Item(\"a\", isV.content) # identity function for copula as well\n",
    "isV * (a * (gray * cat * (inP * texas)))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "np = ((gray * cat) * (inP * texas))\n",
    "vp = (isV * (a * np))\n",
    "sentence2 = julius * vp\n",
    "sentence2"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence1.results[0]"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence1.results[0].tree()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence2.results[0].tree()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "One of the infamous exercise examples from Heim and Kratzer (names different):\n",
    "\n",
    "    (1) Julius is a gray cat in Texas fond of John.\n",
    " \n",
    "First let's get rid of all the extra readings, to keep this simple."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "demo_hk_system.get_rule(\"PM\").commutative = True"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "fond = lang.Item(\"fond\", \"L x_e : L y_e : Fond(y)(x)\")\n",
    "ofP = lang.Item(\"of\", \"L x_e : x\")\n",
    "sentence3 = julius * (isV * (a * (((gray * cat) * (inP * texas)) * (fond * (ofP * john)))))\n",
    "display(sentence3[0].source_tree())\n",
    "sentence3"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "sentence3.tree()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The _Composite_ class subclasses _nltk.Tree_, and so supports the things that class does.  E.g. []-based paths:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "parse_tree3 = sentence3.results[0]\n",
    "parse_tree3[1][1][1].tree()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "There is support for traces and indexed pronouns, using the PA rule.  (The implementation may not be what you expect.)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "binder = lang.Binder(23)\n",
    "binder2 = lang.Binder(5)\n",
    "t = lang.Trace(23, types.type_e)\n",
    "t2 = lang.Trace(5)\n",
    "display(t, t2, binder)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "((t * gray))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "b1 = (binder * (binder2 * (t * (inP * t2))))\n",
    "b2 = (binder2 * (binder * (t * (inP * t2))))\n",
    "display(b1, b2)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "b1.trace()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "b1.results[0].tree()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Composition in tree structures\n",
    "\n",
    "Some in-progress work: implementing tree-based computation, and top-down/deferred computation\n",
    "\n",
    "* using nltk Tree objects.\n",
    "* system for deferred / uncertain types -- basic inference over unknown types\n",
    "* arbitrary order of composition expansion.  (Of course, some orders will be far less efficient!)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "lang.set_system(lang.hk_system)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%%lamb\n",
    "||gray|| = L x_e : Gray_<e,t>(x)\n",
    "||cat|| = L x_e : Cat_<e,t>(x)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "t2 = Tree(\"S\", [\"NP\", \"VP\"])\n",
    "t2"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "t2 = Tree(\"S\", [\"NP\", \"VP\"])\n",
    "r2 = lang.compose(t2)\n",
    "r2.tree()\n",
    "r2.paths()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "Tree = lamb.utils.get_tree_class()\n",
    "t = Tree(\"NP\", [\"gray\", Tree(\"N\", [\"cat\"])])\n",
    "t"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "t2 = lang.CompositionTree.tree_factory(t)\n",
    "r = lang.compose(t2)\n",
    "r"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r.tree()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r = lang.get_system().expand_all(t2)\n",
    "r"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r.tree()"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "r.paths()"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "&nbsp;\n",
    "\n",
    "## Some future projects, non-exhaustive ##\n",
    "\n",
    "* complete fragment of Heim and Kratzer\n",
    "* In general: more fragments!\n",
    "* extend fragment coverage.  Some interesting targets where interactivity would be useful to understanding:\n",
    "  * Compositional hamblin semantics (partial)\n",
    "  * Compositional DRT (partial)\n",
    "  * QR\n",
    "* underlying model theory.\n",
    "* various improvements to the graphics -- trees (d3? graphviz?), interactive widgets, ...\n",
    "* full latex output (trees in tikz-qtree and so on).\n",
    "\n",
    "Longer term:\n",
    "\n",
    "* integration with SymPy (?)\n",
    "* deeper integration with nltk.\n",
    "* parsing that makes less use of python `eval`, and is generally less ad-hoc.\n",
    "  * this is an issue where in principle, a language like Haskell is a better choice than python.  But I think the usability / robustness of python and its libraries has the edge here overall, not to mention ipython notebook...\n",
    "* toy spatial language system\n",
    "* side-by-side comparison of e.g. multiple analyses of presupposition projection"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": []
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Lambda Notebook (Python 3)",
   "language": "python",
   "name": "lambda-notebook"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.12.0"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 4
}