<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://lambda-the-ultimate.org">
<channel>
 <title>Lambda the Ultimate - Type Theory</title>
 <link>http://lambda-the-ultimate.org/taxonomy/term/21/0</link>
 <description></description>
 <language>en</language>
<item>
 <title>Unchecked Exceptions can be Strictly More Powerful than Call/CC</title>
 <link>http://lambda-the-ultimate.org/node/2966</link>
 <description>&lt;p &gt;Here&#039;s a little light reading for your day-after-Labor-Day (or whatever yesterday was where you live): &lt;a href=&quot;http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.19.694&amp;amp;rep=rep1&amp;amp;type=pdf&quot;&gt;Unchecked Exceptions can be Strictly More Powerful than Call/CC&lt;/a&gt;, Mark Lillibridge and Olivier Danvy, 1999, Higher-Order and Symbolic Computation.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We demonstrate that in the context of statically-typed purely-functional lambda calculi without recursion, unchecked exceptions (e.g., SML exceptions) can be strictly more powerful than call/cc. More precisely, we prove that a natural extension of the simply-typed lambda calculus with unchecked exceptions is strictly more powerful than all known sound extensions of Girard’s Fω (a superset of the simply-typed lambda calculus) with call/cc. This result is established by showing that the first language is Turing complete while the later languages permit only a subset of the recursive functions to be written.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;I have to say that on seeing the title I was surprised: I cut my functional teeth on Scheme and every baby Schemer sucks up the knowledge that call/cc lets you create all manner of flow control including exceptions.  But, as the paper makes clear, that&#039;s not necessarily the case in a statically-typed context.&lt;/p&gt;
&lt;p &gt;Edit: Citeseerx was not responding very well, here&#039;s an &lt;a href=&quot;http://www.hpl.hp.com/personal/Mark_Lillibridge/Unchecked_Exceptions/hosc99.pdf&quot;&gt;alternative URL&lt;/a&gt; for the paper.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Tue, 02 Sep 2008 11:39:20 -0400</pubDate>
</item>
<item>
 <title>Relational Parametricity and Units of Measure</title>
 <link>http://lambda-the-ultimate.org/node/2959</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://research.microsoft.com/~akenn/units/RelationalParametricityAndUnitsOfMeasure.pdf&quot;&gt;Relational Parametricity and Units of Measure&lt;/a&gt;, Andrew J. Kennedy, POPL 1997.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Type systems for programming languages with numeric types can be extended to support the checking of units of measure. Quantification over units then introduces a new kind of parametric polymorphism with a corresponding Reynolds-style representation independence principle: that the behaviour of programs is invariant under changes to the units used. We prove this `dimensional invariance&#039; result and describe four consequences.&lt;/p&gt;
&lt;p &gt;The first is that the type of an expression can be used to derive equations which describe its properties with respect to scaling (akin to Wadler&#039;s `theorems for free&#039; for&lt;br &gt;
System F). Secondly there are certain types which are inhabited only by trivial terms. For example, we prove that a fully polymorphic square root function cannot&lt;br &gt;
be written using just the usual arithmetic primitives. Thirdly we exhibit interesting isomorphisms between types and for first-order types relate these to the central theorem of classical dimensional analysis. Finally we suggest that for any expression whose behaviour is dimensionally invariant there exists some equivalent expression whose type reflects this behaviour, a consequence of which would be a full abstraction result for a model of the language.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;There&#039;s a new release of F# coming out with support for measure types, and so I thought I&#039;d post a link to Andrew&#039;s paper about the subject. Now, if you&#039;ve done any physics or engineering, you&#039;re probably familiar with the fact that units can sometimes really strongly constrain what form your equations can take. If you studied dimensional analysis more carefully than I did, you might even have learned that this is a consequence of the &lt;a href=&quot;http://en.wikipedia.org/wiki/Buckingham_%CF%80_theorem&quot;&gt;Buckingham pi theorem&lt;/a&gt; -- you can prove that if you have an equation with n variables involving k physical units, you can recast it as an equation with (n - k) dimension-free variables. Kennedy shows that the analogue of this theorem for programs in his language is a form of parametricity result at first order, which is quite slick.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Sat, 30 Aug 2008 06:28:55 -0400</pubDate>
</item>
<item>
 <title>Differentiating regions</title>
 <link>http://lambda-the-ultimate.org/node/2928</link>
 <description>&lt;p &gt;As a follow up to the &lt;a href=&quot;http://lambda-the-ultimate.org/node/2926&quot;&gt;previous post&lt;/a&gt;, check out how Chung-chieh Shan applied regions to a seemingly unrelated problem. &lt;a href=&quot;http://conway.rutgers.edu/~ccshan/wiki/blog/posts/Differentiation/&quot;&gt;His post&lt;/a&gt; begins by explaining how automatic (numerical)  partial differentiation can be implemented, and goes on to show how to use regions to avoid mixing-up the variables being differentiated.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/5">Fun</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Fri, 08 Aug 2008 15:44:01 -0400</pubDate>
</item>
<item>
 <title>Lightweight Monadic Regions</title>
 <link>http://lambda-the-ultimate.org/node/2926</link>
 <description>&lt;small&gt;Oleg Kiselyov and Chung-chieh Shan. &lt;a href=&quot;http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf&quot;&gt;Lightweight Monadic Regions&lt;/a&gt;. Haskell&#039;08.&lt;/small&gt;
&lt;blockquote&gt;
We present Haskell libraries that statically ensure the safe use of resources such as file handles. We statically prevent accessing an already closed handle or forgetting to close it. The libraries can be trivially extended to other resources such as database connections and graphic contexts...&lt;p&gt;
Region annotations are part of an expression&#039;s inferred type. Our new Haskell encoding of monadic regions as monad transformers needs no witness terms. It assures timely deallocation even when resources have markedly different lifetimes and the identity of the longest-living resource is determined only dynamically.&lt;p&gt;
For contrast, we also implement a Haskell library for manual resource management, where deallocation is explicit and safety is assured by a form of linear types. We implement the linear typing in Haskell with the help of phantom types and a parameterized monad to statically track the type-state of resources.
&lt;/blockquote&gt;&lt;p&gt;
I am starting to think we need a department for effect systems and related topics (though we managed without a monads department!)...&lt;p&gt;
You&#039;ll probably want to read the code, so &lt;a href=&quot;http://okmij.org/ftp/Computation/resource-aware-prog/&quot;&gt;go ahead&lt;/a&gt;. The code makes it plain which features of the type system are needed to achieve the end result.
</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/17">Software Engineering</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Wed, 06 Aug 2008 12:57:09 -0400</pubDate>
</item>
<item>
 <title>Parametric Higher-Order Abstract Syntax for Mechanized Semantics</title>
 <link>http://lambda-the-ultimate.org/node/2853</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://adam.chlipala.net/papers/PhoasICFP08/&quot;&gt;Parametric Higher-Order Abstract Syntax for Mechanized Semantics&lt;/a&gt;&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We present &lt;i exsl=&quot;http://exslt.org/common&quot;&gt;parametric higher-order abstract syntax (PHOAS)&lt;/i&gt;, a new approach to formalizing the syntax of programming languages in computer proof assistants based on type theory.  Like higher-order abstract syntax (HOAS), PHOAS uses the meta language&#039;s binding constructs to represent the object language&#039;s binding constructs.  Unlike HOAS, PHOAS types are definable in general-purpose type theories that support traditional functional programming, like Coq&#039;s Calculus of Inductive Constructions.  We walk through how Coq can be used to develop certified, executable program transformations over several statically-typed functional programming languages formalized with PHOAS; that is, each transformation has a machine-checked proof of type preservation and semantic preservation.  Our examples include CPS translation and closure conversion for simply-typed lambda calculus, CPS translation for System F, and translation from a language with ML-style pattern matching to a simpler language with no variable-arity binding constructs.  By avoiding the syntactic hassle associated with first-order representation techniques, we achieve a very high degree of proof automation.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;I was aware of this some months ago now, but held back commenting on it at Adam&#039;s request until it had been accepted for publication, which it now apparently has. This is (one element of) Adam&#039;s continued work on &lt;a href=&quot;http://ltamer.sourceforge.net&quot;&gt;LambdaTamer&lt;/a&gt;, his Coq-based environment for building certified compilers. There is a new version of LambdaTamer using this parametric higher-order abstract syntax approach. The new version also works in current and future versions of Coq, unlike the previous version. Finally, Adam is apparently working on a paper regarding &quot;type-theoretic denotational semantics for higher order, impure object languages&quot; and is post-docing with Greg Morrisett. The relationship between Adam&#039;s work and the &lt;a href=&quot;http://lambda-the-ultimate.org/node/2638&quot;&gt;YNot project&lt;/a&gt; is a bit unclear to me; perhaps either Adam or Greg could help clarify that.&lt;/p&gt;
&lt;p &gt;&lt;b &gt;Update:&lt;/b&gt; Whoops. I got ahead of myself and neglected to notice that the paper is not actually yet available, although the new version of LambdaTamer is. So at the moment, this story is merely to note that the paper exists and to provide a link to the new LambdaTamer. My apologies to Adam and the LtU readership.&lt;/p&gt;
&lt;p &gt;&lt;b &gt;2nd Update:&lt;/b&gt; The paper is now available at the link, in either PostScript or PDF form.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/8">Implementation</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Mon, 16 Jun 2008 11:44:57 -0400</pubDate>
</item>
<item>
 <title>Types Considered Harmful</title>
 <link>http://lambda-the-ultimate.org/node/2828</link>
 <description>&lt;p &gt;Benjamin C. Pierce&#039;s presentation slides (in PDF) for his talk on &lt;a href=&#039;http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf&#039;&gt;Types Considered Harmful&lt;/a&gt;.  The talk starts out discussing some of the general advantages and disadvantages of static typing.  But the aim of the talk centers on the problems of building a type checker for the &lt;a href=&#039;http://www.seas.upenn.edu/~harmony/&#039;&gt;Boomerang Programming Languague&lt;/a&gt; (an offshoot of harmony).&lt;/p&gt;
&lt;blockquote &gt;&lt;ul &gt;
&lt;li &gt;Boomerang language design as an example of
&lt;ol &gt;
&lt;li &gt;the need for very precise types&lt;/li&gt;
&lt;li &gt;some of the technical problems they raise&lt;/li&gt;
&lt;/ol&gt;
&lt;/li&gt;
&lt;li &gt;Contracts as an attractive way of addressing some of these issues&lt;/li&gt;
&lt;/ul&gt;&lt;/blockquote&gt;
&lt;p &gt;Pierce&#039;s work is currently centered on creating a PL for &lt;a href=&#039;http://lambda-the-ultimate.org/node/1526&#039;&gt;Bidirectional Programming&lt;/a&gt;.  A work in progress but it&#039;s interesting to see the thought process behind language design in real-time.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Fri, 30 May 2008 14:16:19 -0400</pubDate>
</item>
<item>
 <title>Flexible types: Robust type inference for first-class polymorphism</title>
 <link>http://lambda-the-ultimate.org/node/2781</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://research.microsoft.com/users/daan/download/papers/hml-tr.pdf&quot;&gt;Flexible types: Robust type inference for first-class polymorphism&lt;/a&gt;, by Dan Leijen:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;We present HML, a type inference system that supports full firstclass polymorphism where few annotations are needed: only function parameters with a polymorphic type need to be annotated. HML is a simplification of MLF where only flexibly quantified types are used. This makes the types easier to work with from a programmers perspective, and we found that it simplifies the implementation of the type inference algorithm significantly. Still, HML retains much of the expressiveness of MLF, it is robust with respect to small program transformations, and has a simple specification of the type rules with an effective type inference algorithm that infers principal types. A reference implementation of the type system is available at: &lt;a href=&quot;http://research.microsoft.com/users/daan/&quot;&gt;http://research.microsoft.com/users/daan/pubs.html.&lt;/a&gt;&lt;/blockquote&gt;
Seems there&#039;s been a flurry of activity on first-class polymorphism recently, with HML, &lt;a href=&quot;http://lambda-the-ultimate.org/node/2780&quot;&gt;FPH&lt;/a&gt;, and &lt;a href=&quot;http://lambda-the-ultimate.org/node/2779&quot;&gt;HM&lt;sup &gt;F&lt;/sup&gt;&lt;/a&gt; as simpler alternatives to full ML&lt;sup &gt;F&lt;/sup&gt;.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Sun, 20 Apr 2008 12:55:37 -0400</pubDate>
</item>
<item>
 <title>FPH: First-class Polymorphism for Haskell</title>
 <link>http://lambda-the-ultimate.org/node/2780</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://research.microsoft.com/~simonpj/papers/boxy/&quot;&gt;FPH: First-class Polymorphism for Haskell&lt;/a&gt;, by  Dimitrios Vytiniotis, Stephanie Weirich and Simon Peyton Jones:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Languages supporting polymorphism typically have ad-hoc restrictions on where polymorphic types may occur. Supporting “firstclass” polymorphism, by lifting those restrictions, is obviously desirable, but it is hard to achieve this without sacrificing type inference. We present a new type system for higher-rank and impredicative polymorphism that improves on earlier proposals: it is an extension of Damas-Milner; it relies only on System F types; it has a simple, declarative specification; it is robust to program transformations; and it enjoys a complete and decidable type inference algorithm.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Under Related Work, the authors provide a detailed comparison of their system with ML&lt;sup &gt;F&lt;/sup&gt;, and &lt;a href=&quot;http://lambda-the-ultimate.org/node/2779&quot;&gt;HM&lt;sup &gt;F&lt;/sup&gt;&lt;/a&gt;.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Sun, 20 Apr 2008 12:46:58 -0400</pubDate>
</item>
<item>
 <title>HMF: Simple type inference for first-class polymorphism</title>
 <link>http://lambda-the-ultimate.org/node/2779</link>
 <description>&lt;p &gt;&lt;b &gt;&lt;a href=&quot;http://research.microsoft.com/users/daan/download/papers/hmf-tr.pdf&quot;&gt;HMF: Simple type inference for first-class polymorphism&lt;/a&gt;&lt;/b&gt; - Daan Leijen, Draft April 8, 2008.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
HMF is a conservative extension of Hindley-Milner type inference with first-class polymorphism and regular System F types. The system&lt;br &gt;
distinguishes itself from other proposals with simple type rules and a very simple type inference algorithm that is just a small extension&lt;br &gt;
of the usual Damas-Milner algorithm. Given the relative simplicity and expressive power, we feel that HMF can be a very attractive&lt;br &gt;
type system in practice. There is a reference implementation of the type system available at: &lt;a href=&quot;http://research.microsoft.com/users/daan/pubs.html&quot;&gt;http://research.microsoft.com/users/daan/pubs.html&lt;/a&gt;.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;An excellent paper even in its current draft form. I also placed this under the learning category, because Daan&#039;s writing style is lucid enough that the concepts can be understood by relative newcomers to the field of type theory&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/18">Teaching &amp; Learning</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Sun, 20 Apr 2008 12:23:25 -0400</pubDate>
</item>
<item>
 <title>Algebra of programming using dependent types</title>
 <link>http://lambda-the-ultimate.org/node/2771</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.iis.sinica.edu.tw/~scm/pub/mpc08.pdf&quot;&gt;Algebra of programming using dependent types&lt;/a&gt;. S-C. Mu, H-S. Ko, and P. Jansson.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Dependent type theory is rich enough to express that a program satisfies an input/output relational specification, but it could be hard to construct the proof term. On the other hand, &lt;em &gt;squiggolists&lt;/em&gt; know very well how to show that one relation is included in another by algebraic reasoning. We demonstrate how to encode functional and relational derivations in a dependently typed programming language. A program is coupled with an algebraic derivation from a specification, whose correctness is guaranteed by the type system.&lt;/p&gt;
&lt;p &gt;Code accompanying the paper has been developed into an &lt;a href=&quot;http://www.iis.sinica.edu.tw/~scm/2008/aopa/&quot;&gt;Agda library AoPA&lt;/a&gt;.&lt;/p&gt;&lt;/blockquote&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Mon, 14 Apr 2008 16:41:20 -0400</pubDate>
</item>
<item>
 <title>Register Allocation by Proof Transformation</title>
 <link>http://lambda-the-ultimate.org/node/2765</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://citeseer.ist.psu.edu/650314.html&quot;&gt;Register Allocation by Proof Transformation&lt;/a&gt;, Atsushi Ohori. ESOP 2003. &lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
This paper presents a proof-theoretical framework for register allocation that accounts for the entire process of register allocation. Liveness analysis is proof reconstruction (similar to type inference), and register allocation is proof transformation from a proof system with unrestricted variable accesses to the one with restricted variable access. In our framework, the set of registers acts as the ``working set&#039;&#039; of the live variables at each instruction step, which changes during the execution of the code. This eliminates the ad-hoc notion of ``spilling&#039;&#039;. The necessary memory-register moves are systematically incorporated in the proof transformation process. Its correctness is a simple corollary of our construction; the resulting proof is equivalent to the proof of the original code modulo the treatment of structural rules. This yields a simple yet powerful register allocation algorithm. The algorithm has been implemented, demonstrating the feasibility of the framework.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;The idea that making uses of the structural rules explicit gives you proof terms to model register-memory moves is very pretty. Another fun thing to do would be to take a continuation calculus and apply the ideas here to see if it produces a good low-level IR. &lt;/p&gt;
&lt;p &gt;EDIT: Ehud asked for some further exposition, so here goes. &lt;/p&gt;
&lt;p &gt;At a high level, you can think of the need to do register allocation as arising from a mismatch between a programming language and the hardware. In a language, we refer to data using variables, and in any given expression, we can use as many variables as we like. However, when a CPU does stuff, it wants the data to be in registers -- and it has only a small, finite set of them. So when a program is compiled, some variables can be represented by registers, and the rest must be represented by locations in memory (usually on the stack). Whenever the CPU needs to use a variable in memory, there must be explicit code to move it from memory into a register. &lt;/p&gt;
&lt;p &gt;The idea in this paper is to take the typing derivation of a program with an unbounded variable set, and then divide the context into two parts, one representing the register file and the other representing variables in memory. In terms of the implementation, moves between these two zones correspond to register-memory moves; and in terms of logic, this is a use of the &lt;a href=&quot;http://en.wikipedia.org/wiki/Exchange_rule&quot;&gt;structural rule of Exchange&lt;/a&gt;, which permutes the order of variables in a context.&lt;/p&gt;
&lt;p &gt;So this gives us a high-level, machine-independent characterization of the register allocation problem: take a one-zone derivation and convert it to a two-zone derivation. But it gets even better: as long as the register allocation algorithm only adds uses of the structural rules in its transformation, we know that the meaning of the original program is unchanged -- so this method also yields a simple way of proving that a register allocation pass is semantics-preserving. (The fact that this is an easy proof is one indication of the power of this idea.)&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/8">Implementation</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Fri, 11 Apr 2008 18:08:24 -0400</pubDate>
</item>
<item>
 <title>Mechanizing the Metatheory of LF</title>
 <link>http://lambda-the-ultimate.org/node/2764</link>
 <description>&lt;p &gt;Christian Urban, James Cheney, Stefan Berghofer.  &lt;a href=&quot;http://arxiv.org/pdf/0804.1667v1&quot;&gt;Mechanizing the Metatheory of LF&lt;/a&gt;.   Extended tech report accompanying LICS 2008 paper.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
LF is a dependent type theory in which many other formal systems can be conveniently embedded. However, correct use of LF relies on nontrivial metatheoretic developments such as proofs of correctness of decision procedures for LF&#039;s judgments. Although detailed informal proofs of these properties have been published, they have not been formally verified in a theorem prover. We have formalized these properties within Isabelle/HOL using the Nominal Datatype Package, closely following a recent article by Harper and Pfenning. In the process, we identified and resolved a gap in one of the proofs and a small number of minor lacunae in others. Besides its intrinsic interest, our formalization provides a foundation for studying the adequacy of LF encodings, the correctness of Twelf-style metatheoretic reasoning, and the metatheory of extensions to LF.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;This paper is a substantial exercise in applying the approach of Harper and Licata in &lt;a href=&quot;http://lambda-the-ultimate.org/node/1053&quot;&gt;Mechanizing Language Definitions&lt;/a&gt; reported before, and is an advance towards a worthy objective in the &lt;a href=&quot;http://lambda-the-ultimate.org/node/2171&quot;&gt;campaign to mechanise metatheory&lt;/a&gt; that Paul espouses...&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Fri, 11 Apr 2008 08:59:32 -0400</pubDate>
</item>
<item>
 <title>The Disciplined Disciple Compiler</title>
 <link>http://lambda-the-ultimate.org/node/2727</link>
 <description>&lt;blockquote &gt;Disciple is an explicitly lazy dialect of Haskell which includes:
  &lt;ul &gt;
    &lt;li &gt;first class destructive update of arbitrary data.&lt;/li&gt;
    &lt;li &gt;computational effects without the need for state monads.&lt;/li&gt;
    &lt;li &gt;type directed field projections.&lt;/li&gt;
  &lt;/ul&gt;
All this and more through the magic of effect typing.&lt;/blockquote&gt;
&lt;p &gt;The &lt;a href=&#039;http://www.haskell.org/haskellwiki/DDC&#039;&gt;wiki page&lt;/a&gt; has more information, unfortunately there&#039;s &lt;a href=&#039;http://www.haskell.org/haskellwiki/DDC/FurtherReading&#039;&gt;no paper yet&lt;/a&gt; summarizing the ideas and results. Their &lt;a href=&#039;http://www.haskell.org/haskellwiki/DDC/EffectSystem&#039;&gt;effect system&lt;/a&gt; is quite interesting. Some of the ideas &lt;a href=&#039;http://lambda-the-ultimate.org/node/2706&#039;&gt;recently discussed here&lt;/a&gt; are implemented in Disciple.&lt;/p&gt;
&lt;p &gt;via &lt;a href=&#039;http://www.nabble.com/ANN:-The-Disciplined-Disciple-Compiler---alpha-1-td16172459.html&#039;&gt;Haskell Cafe&lt;/a&gt;&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Thu, 20 Mar 2008 10:19:29 -0400</pubDate>
</item>
<item>
 <title>Uniqueness Typing Simplified</title>
 <link>http://lambda-the-ultimate.org/node/2708</link>
 <description>&lt;p &gt;&lt;a href=&quot;https://www.cs.tcd.ie/~devriese/pub/ifl07-paper.pdf&quot;&gt;Uniqueness Typing Simplified&lt;/a&gt;, by Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;We present a uniqueness type system that is simpler than both Clean’s uniqueness system and a system we proposed previously. The new type system is straightforward to implement and add to existing compilers, and can easily be extended with advanced features such as higher rank types and impredicativity. We describe our implementation in Morrow, an experimental functional language with both these features. Finally, we prove soundness of the core type system with respect to the call-by-need lambda calculus.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Uniqueness typing is related to linear typing, and their &lt;a href=&quot;http://lambda-the-ultimate.org/node/1548&quot;&gt;differences have been discussed here before&lt;/a&gt;. Linear types have &lt;a href=&quot;http://lambda-the-ultimate.org/node/1068&quot;&gt;many applications&lt;/a&gt;. This paper describes the difference between linear and unique types:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;In linear logic, variables of a non-linear type can be coerced to a linear type (dereliction). Harrington phrases it well: in linear logic, &quot;linear&quot; means &quot;will not be duplicated&quot; whereas in uniqueness typing, &quot;unique&quot; means &quot;has not been duplicated&quot;.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;In contrast to other papers on substructural typing, such as Fluet&#039;s thesis &lt;a href=&quot;http://lambda-the-ultimate.org/node/2551&quot;&gt;Monadic and Substructural Type Systems for Region-Based Memory Management&lt;/a&gt;, this paper classifies uniqueness attributes by a kind system. This possibility was mentioned in Fluet&#039;s thesis as well, Section 4.2, footnote 8, though the technique used here seems somewhat different.&lt;/p&gt;
&lt;p &gt;Uniqueness typing is generally used to &lt;a href=&quot;http://lambda-the-ultimate.org/node/2543&quot;&gt;tame side-effects&lt;/a&gt; in purely functional languages. Uniqueness types have also &lt;a href=&quot;http://lambda-the-ultimate.org/node/1180&quot;&gt;been contrasted with monads on LTU&lt;/a&gt;, which are also used to tame effects, among other things. One point not discussed in that thread, is how straightforward it is to compile each approach into efficient code. It seems clear that uniqueness types have a straightforward, efficient compilation, but it&#039;s not clear to me how efficient monads can be, and how much work is required to make them efficient. This may make uniqueness or substructural types more suitable for just-in-time compilers than monads.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Mon, 03 Mar 2008 10:14:16 -0500</pubDate>
</item>
<item>
 <title>History of Lambda-Calculus and Combinatory logic</title>
 <link>http://lambda-the-ultimate.org/node/2679</link>
 <description>&lt;small&gt;F. Cardone and J. R. Hindley. &lt;a href=&quot;http://www-maths.swan.ac.uk/staff/jrh/papers/JRHHislamWeb.pdf&quot;&gt;History of Lambda-Calculus and Combinatory logic&lt;/a&gt;. To appear as a chapter in Volume 5 of the Handbook of the History of Logic.&lt;/small&gt;&lt;p&gt;
From the introduction:&lt;p&gt;
&lt;blockquote&gt;
Seen in outline, the history of LC and CL splits into three main periods: first, several years of intensive and very fruitful study in the 1920s and ’30s; next, a middle period of nearly 30 years of relative quiet; then in the late 1960s an upsurge of activity stimulated by developments in higher-order function theory, by connections
with programming languages, and by new technical discoveries. The fruits of the first period included the first-ever proof that predicate logic is undecidable. The results of the second attracted very little  non-specialist interest, but included completeness, cut-elimination and standardization theorems (for example) that found many uses later. The achievements of the third, from the 1960s onward, included constructions and analyses of models, development of polymorphic type systems, deep analyses of the reduction process, and many others probably well known to the reader. The high level of activity of this period continues today.&lt;/blockquote&gt;&lt;P&gt;
Beware: This is a long paper (but less than you might expect it to be by looking at the page count: about half the pages are dedicated to the bibliography).&lt;p&gt;
In the announcement on the TYPES Forum the authors invited comments, suggestions and additional information on the topics of the paper, namely the development of lambda-calculi and combinatory logic from the prehistory (Frege, Peano and Russell) to the end of 20th century.
</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/7">History</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Tue, 19 Feb 2008 14:21:52 -0500</pubDate>
</item>
</channel>
</rss>
