Fritz Obermeyerinference engineering, untyped λ-calculus, Bayesian pragmatism, live coding, etc.
http://fritzo.github.io/
Sat, 02 Jul 2016 18:08:23 +0000Sat, 02 Jul 2016 18:08:23 +0000Jekyll v3.1.6A computational comonad for quoting
<p>Suppose you’re writing a library in a language with macros (e.g. in Lisp),
and you want to be able to refactor your library without breaking user code.
Could the language designers guarantee safety by baking constraints into the language’s quoting interface?</p>
<p>Consider the spectrum of quoting interfaces, from unsafe to safe.
On the unsafe end of the spectrum, users have full access to source, and no changes are safe.
Lisp is on the unsafe end.
On the safe end of the spectrum, users can only evaluate your code, and you can safely replace any chunk of code with a Scott-equivalent chunk of code.
In the middle of the spectrum, we could consider quoting modulo a weak notion of equality.
For example, quoting modulo alpha-equivalence would safely permit you to rename-refactor your library.</p>
<p>Let’s define a quoting interface in the form of a <em>computational comonad</em> <a href="#1">[1]</a>:</p>
<pre><code class="language-coq">Quoted : type -> type.
lift : forall (t1 t2:type), Quoted(t1->t2) -> Quoted t1 -> Quoted t2.
eval : forall (t:type), Quoted t -> t.
{-} : forall (t:type), t -> Quoted t.
quote : forall (t:type), Quoted t -> Quoted(Quoted t).
</code></pre>
<p>where <code class="highlighter-rouge">Quoted</code> and <code class="highlighter-rouge"><span class="p">{</span><span class="err">-</span><span class="p">}</span></code> are in the meta language,
and <code class="highlighter-rouge">lift</code>, <code class="highlighter-rouge">eval</code>, and <code class="highlighter-rouge">quote</code>, are in the object language
(<code class="highlighter-rouge">quote</code> is just the object-level version of <code class="highlighter-rouge"><span class="p">{</span><span class="err">-</span><span class="p">}</span></code>).
We require equations</p>
<pre><code class="language-coq">forall (t:type) (x:t), eval{x} = x.
forall (t:type) (x:Quoted t), eval(quote x) = x.
forall (t:type) (x:Quoted t), quote{x} = {{x}}.
forall (t1 t2:type) (f:t1->t2) (x:t1), lift{f}{x} = {f x}.
</code></pre>
<p>Note that in terms of a Kleisli triple, the pair <code class="highlighter-rouge">(Quoted,lift)</code> is the functor,
<code class="highlighter-rouge">eval</code> is the counit, and we can define the cobind operator by</p>
<pre><code class="language-coq">cobind : forall (t1:type) (t2:type),
(Quoted t1 -> t2) -> Quoted t1 -> Quoted t2.
cobind t1 t2 f x := {f x}.
</code></pre>
<p>This <code class="highlighter-rouge">cobind</code> is in the meta language, not the object language, but we can define a more convenient object version</p>
<pre><code class="language-coq">cobind' : forall (t1:type) (t2:type),
Quoted(Quoted t1 -> t2) -> Quoted t1 -> Quoted t2.
cobind' f x := lift(quote f)(quote x).
</code></pre>
<p>So far we can’t do anything with the quoted code, except evaluate it.
It’s enough to add an equality predicate (a Church delta) for quoted terms, assuming some notion of equality.</p>
<pre><code class="language-coq">equiv : forall (t:type), Quoted t -> Quoted t -> bool.
</code></pre>
<p>The <code class="highlighter-rouge">equiv</code> operator is at the object level,
and returns the object level <code class="highlighter-rouge">bool</code>.
<code class="highlighter-rouge">equiv</code> makes each <code class="highlighter-rouge">Quoted</code> type into a numeral system
(a flat domain with a Church delta),
and we can define all sorts of safe macros that transform quoted code.</p>
<p>We can tune the safety of our <code class="highlighter-rouge">Quoted</code> comonad by tuning the coarseness of this <code class="highlighter-rouge">equiv</code> operator.
In <a href="#2">[2]</a>, I explored the extreme safe end of the spectrum: quoting modulo Scott-equality.</p>
<h2 id="references">References</h2>
<ul>
<li>[1] <a name="1"></a>
Stephen Brookes, Shai Geva (1991)
“Computational Comonads and Intensional Semantics”
<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4952&rep=rep1&type=pdf">(pdf)</a></li>
<li>[2] <a name="2"></a>
Fritz Obermeyer (2009)
“Automated Equational Reasoning in Nondeterministic λ-Calculi Modulo Theories H∗”
<a href="http://fritzo.org/thesis.pdf">(pdf)</a></li>
</ul>
Sat, 02 Jul 2016 00:00:00 +0000
http://fritzo.github.io/logic/lambda/2016/07/02/quoting-comonad.html
http://fritzo.github.io/logic/lambda/2016/07/02/quoting-comonad.htmllogiclambdaNew blog platform: github pages + jekyll<p>I’m in the process of moving old content from wordpress and miscellaneous markdown files to a new platform: github pages + jekyll.
I’m trying to date older documents by their original, earliest date, even if small updates have been made afterwards.</p>
<p>Let me know if you have any suggestions!</p>
Sun, 21 Feb 2016 00:00:00 +0000
http://fritzo.github.io/meta/2016/02/21/new-blog-platform.html
http://fritzo.github.io/meta/2016/02/21/new-blog-platform.htmlmetaPomagma: an extensional programming environment for developing computational behaviors<p>(this is excerpted from the Pomagma project’s <a href="https://github.com/fritzo/pomagma/blob/master/doc/philosophy.md">doc/philosophy.md</a>)</p>
<h1 id="pomagma">Pomagma</h1>
<h2 id="an-experiment-in-extensional-programming">An experiment in Extensional Programming</h2>
<p>The <a href="https://github.com/fritzo/pomagma">Pomagma</a>
is an extensional programming environment
for developing computational behaviors.</p>
<p>Extensionality is the idea that two programs can be considered equal
if their input-output pairs are all equal,
in particular ignoring resource usage, run-time complexity, and space.
The opposite of extensionality is intensionality, the idea that programs
should be considered equal only if they convey the same concept intended
by the programmer.
Modern programming is mired in far-too intensional practices,
where incidental artifacts of code
(whitespace, style, line order, local variable names, arbitrary imperatives)
frustrate many actions that would be easier with an extensional view
(code-search, verification, optimization, automatic parallelization).
Better programming practice might start with
syntax-directed editors, tools for code refactoring,
purely functional and declarative languages,
and precise type systems.
But a key missing concept is the use of extensionality.
Pomagma is an experiment to see how far extensionality can be pushed.</p>
<p>Pomagma is founded on a simple untyped pure functional programming language,
the non-deterministic λ-calculus <a href="#1">[1]</a>,
and a “maximally-coarse” semantics <a href="#2">[2]</a>
where as many programs as possible
are considered equal.
At the core of the Pomagma system is an inference engine
that is used for verification and search/suggestion.</p>
<h3 id="language-the-lambda-join-calculus">Language: the λ-join-calculus</h3>
<p>The λ-join-calculus is a λ-calculus with a join operation,
written <code class="highlighter-rouge">x|y</code> indicating nondeterministic or concurrent choice.
We think of join as concurrency in the sense that
<code class="highlighter-rouge">x|y</code> halts iff either of <code class="highlighter-rouge">x</code> or <code class="highlighter-rouge">y</code> halt.
Nondeterminism allows one to specify what doesn’t matter in a program:
symmetry, order of decoupled operations, etc.</p>
<h3 id="semantics-observational-equivalence">Semantics: observational equivalence</h3>
<p>Naively, two programs might be considered equal if their outputs agree at all inputs.
However, in a space where programs can be applied to programs,
and where programs may sometimes halt,
one needs to define this equational semantics carefully by coinduction.
It turns out to be be enough to say that two programs <code class="highlighter-rouge">x</code> and <code class="highlighter-rouge">y</code> are equal
iff for every program <code class="highlighter-rouge">f</code>, <code class="highlighter-rouge">f x</code> halts iff <code class="highlighter-rouge">f y</code> halts
(or when modeling probabilistic programs,
that <code class="highlighter-rouge">f x</code> halts exactly as often as <code class="highlighter-rouge">f y</code> halts).</p>
<h3 id="type-system-nondeterministic-polymorphism">Type System: nondeterministic polymorphism</h3>
<p>Pomagma provides a rich type system by simulating types within the base system.
The first idea, due to Dana Scott <a href="#3">[3]</a>,
is to define a term <code class="highlighter-rouge">x</code> to have type <code class="highlighter-rouge">t</code>
iff <code class="highlighter-rouge">x</code> is a fixed-point of <code class="highlighter-rouge">t</code>, i.e., <code class="highlighter-rouge">x:t</code> iff <code class="highlighter-rouge">t x = x</code>.
The second idea, from <a href="#4">[4]</a>,
is to use the combination of non-determinism and
observational equivalence to define higher-order polymorphic types <code class="highlighter-rouge">t</code>
inside the untyped base language.</p>
<h3 id="reflection-extensional-quoting">Reflection: extensional quoting</h3>
<p>Pomagma takes an extensional approach to quoting.
Opposite to Kleene’s intensional quoting convention,
where codes <code class="highlighter-rouge">x</code> are considered intensional and were evaluated <code class="highlighter-rouge"><span class="p">{</span><span class="err">x</span><span class="p">}</span></code>
to produce functions, Pomagma’s language treats codes <code class="highlighter-rouge">x</code> as
extensional and requires quoting <code class="highlighter-rouge"><span class="p">{</span><span class="err">x</span><span class="p">}</span></code> to prevent evaluation.
Moreover by consistently extending the λ-join-calculus,
we can achieve the rule: if it is provable that <code class="highlighter-rouge">x = y</code>, then also <code class="highlighter-rouge"><span class="p">{</span><span class="err">x</span><span class="p">}</span><span class="w"> </span><span class="err">=</span><span class="w"> </span><span class="p">{</span><span class="err">y</span><span class="p">}</span></code>.
In Pomagma, quoting serves to flatten the information ordering,
rather than preserve intension.</p>
<h3 id="logical-strength-predicative-mathematics">Logical strength: predicative mathematics</h3>
<p>Pomagma consistently extends λ-join-calculus with
a partial equation-deciding oracle.
This allows equations to be interpreted back into the language as terms.
Iterating, we can thus write equations of strength all the way up the
hyperarithmetic hierarchy to Δ<sub>1</sub><sup>1</sup>,
and provide a foundation for all of Sol Feferman’s predicative mathematics
<a href="#5">[5]</a>.</p>
<h3 id="code-format-a-database-of-definitions-and-assertions">Code Format: a database of definitions and assertions</h3>
<p>Pomagma’s coding interface minimizes intensional data.
Rather than a file of lines of code,
Pomagma stores a database of unordered lines of code.
Each line is either a definition (an explicit declaration)
or an assertion (an implicit declaration).
All defined variables are globally visible.
The behavior of a line of code as a function of its referenced global variables
is treated extensionally.
Lines are stored in “compiled” form and are “decompiled” on the fly while editing.
Multi-line views of code are also generated on the fly by querying the line database.
(Contrast this with the archaic tree-of-files-of-lines-of-code format
that this very repo is stored in.)</p>
<hr />
<ul>
<li>[1] <a name="1"></a>
the λ-join-calculus in terms of Scott’s information ordering.</li>
<li>[2] <a name="2"></a>
Hyland and Wadsworth’s λ-theory
<it>H</it>
<p><sup>*</sup> of observational equivalence,
the equational theory of Scott’s D<sub>∞</sub> model.</p>
</li>
<li>[3] <a name="3"></a>
<a href="http://www.cs.ox.ac.uk/files/3287/PRG05.pdf">“Datatypes as Lattices”</a>
-Dana Scott (1976)</li>
<li>[4] <a name="4"></a>
Pomagma began as a PhD <a href="http://fritzo.org/thesis.pdf">thesis</a>
and <a href="http://github.com/fritzo/Johann">codebase</a>.</li>
<li>[5] <a name="5"></a>
See
<a href="http://math.stanford.edu/~feferman/papers/predicativity.pdf">“Predicativity”</a>
or <a href="http://math.stanford.edu/~feferman/papers.html">other papers</a>
by Solomon Feferman.</li>
</ul>
Thu, 15 Aug 2013 00:00:00 +0000
http://fritzo.github.io/logic/lambda/2013/08/15/pomagma.html
http://fritzo.github.io/logic/lambda/2013/08/15/pomagma.htmllogiclambdaThe Rational Keyboard<p>While traveling in Vietnam, I wrote a little browser app to experiment with automated reasoning about harmony in just intonation.
The resulting <a href="http://fritzo.org/keys">Rational Keyboard</a> is kind of like a piano whose keys move around to make consonant notes & chords easy to play.
One cool thing about an instrument with moving keys is that it can access all rational tones (a dense infinite set) with only a finite number of keys visible at any time.</p>
<p>The app currently only seems to run in Chrome (audio synthesis is a recent browser feature).
If you’d like to see how it works, or help getting it working in other browsers, check out the <a href="https://github.com/fritzo/rationalkeyboard">github page</a> or just</p>
<div class="language-bash highlighter-rouge"><pre class="highlight"><code>git clone git@github.com:fritzo/rationalkeyboard.git
</code></pre>
</div>
<p>Update: The app now appears to run in Firefox as well.</p>
Sun, 08 Jan 2012 00:00:00 +0000
http://fritzo.github.io/music/art/web/2012/01/08/rational-keyboard.html
http://fritzo.github.io/music/art/web/2012/01/08/rational-keyboard.htmlmusicartwebComputational aesthetics for foundations of math<p>A foundation for mathematics is a formal system (language + logic) in which all other formal systems can be expressed and reasoned about.
By Goedel’s first incompleteness theorem, such systems are never logically complete (with finite axiomatizations).
Thus any foundation of math leaves some questions unanswered.
Logicians must ask the ongoing question “what new axioms should be assumed”.
So let us ask,</p>
<p>What new axioms should be assumed [in any foundation of math]? Of course no algorithm can decide which axioms to add, otherwise we could simply add a finite axiomatization of the algorithm.
What new axioms should be assumed [in any foundation of math]? Of course no algorithm can decide which axioms to add, otherwise we could simply add a finite axiomatization of the algorithm.
Instead logicians, e.g. professional set theorists, employ the aesthetic rule: “good axioms lead to elegant theories”.
So what is an elegant theory? In elegant theories, the world is simple: sensible things are easy to say, and senseless jabber is difficult to say.
The mathematical literature itself serves as a data set of sensible statements, expressed as sets (as e.g. in a Kieffer et al. <a href="#1">[1]</a>).
So elegant theories should simply shrink the remaining [by contrast, senseless] part of the universe of sets to be as small as possible.</p>
<p>Which axioms shrink the remaining universe? What is a small model of the universe of sets? In our present application, we can formalize by defining a notion random set, and minimizing the universe’s entropy (a soft notion of size).
Since we’re interested in writing simple math, let’s generate random sets by picking random expressions denoting sets.
Formally, we define a probabilistic grammar, whose parameters are statistically fit to a corpus of real-world expressions (the mathematical literature).
Then we can simply rank axiom candidates by the entropy change they induce on the universe of sets.</p>
<p>This aesthetic algorithm works in theory, but founding math in set theory leads to practical difficulties: sets have a complicated syntax (it’s even undecidable whether a given set expression is actually a set), and complicated reasoning principles.
The grammatically-simplest foundation for computable mathematics is arguably <a href="http://en.wikipedia.org/wiki/Combinatory_logic">Combinatory Logic</a>, a language with two constants and a single binary operation.
In fact combinatory algebra can be extended by a couple more constants, and a few more axioms, so that all mathematical questions can be posed as equations between these extended terms.</p>
<p>My <a href="http://fritzo.org/thesis.pdf">Ph.D. research</a> focussed on implementing and assessing the min-entropy aesthetic algorithm, and working on the particular foundation of an extended combinatory algebra.</p>
<ul>
<li>[1] <a name="1"></a>
Steven Kieffer, Jeremy Avigad, Harvey Friedman (2009)
“A language for mathematical knowledge management”
<a href="http://logika.uwb.edu.pl/studies/download.php?volid=31&artid=sk&format=PDF">pdf</a></li>
</ul>
Mon, 29 Sep 2008 00:00:00 +0000
http://fritzo.github.io/logic/computation/2008/09/29/computational-aesthetics.html
http://fritzo.github.io/logic/computation/2008/09/29/computational-aesthetics.htmllogiccomputation