<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://lambda-the-ultimate.org">
<channel>
 <title>Lambda the Ultimate - Lambda Calculus</title>
 <link>http://lambda-the-ultimate.org/taxonomy/term/20/0</link>
 <description>LC and variations.</description>
 <language>en</language>
<item>
 <title>A located lambda calculus</title>
 <link>http://lambda-the-ultimate.org/node/2798</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://homepages.inf.ed.ac.uk/wadler/papers/located-lambda/located-lambda.pdf&quot;&gt;A located lambda calculus&lt;/a&gt;. Ezra Cooper and Philip Wadler. Submitted to ICFP 2008.&lt;br &gt;
&lt;blockquote &gt;&lt;p &gt;
Several recent language designs have offered a unified language for programming a distributed system; we call these &quot;location-aware&quot; languages. These languages provide constructs that allow the programmer to control the location (the choice of host, for example) where a piece of code should run, which can be useful for security or performance reasons. On the other hand, a central mantra of web engineering insists that web servers should be &quot;stateless&quot;: that no &quot;session state&quot; should be maintained on behalf of individual clients---that is, no state that pertains to the particular point of the interaction at which a client program resides. Thus far, most implementations of unified location-aware languages have ignored this precept, usually keeping a process for each client running on the server, or otherwise storing state information in memory. We show how to implement a location-aware language on top of the stateless-server model.&lt;br &gt;
&lt;/blockquote&gt;
&lt;p &gt;
This paper is technical, and I assume most LtU members will mainly read sections 1, 5 &amp;amp; 6. Figure 5 is definition of the located LC. &lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/16">Parallel/Distributed</category>
 <pubDate>Sun, 04 May 2008 15:25:18 -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>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>
<item>
 <title>Project LambdaCan</title>
 <link>http://lambda-the-ultimate.org/node/2661</link>
 <description>&lt;blockquote &gt;&lt;p &gt;You can get soup in a can. You can get bread in a can. Now the long wait is over! You can finally get Lambda Calculus in a can...&lt;a href=&quot;http://alum.wpi.edu/~tfraser/Software/Arduino/lambdacan.html&quot;&gt;Project LambdaCan&lt;/a&gt; takes [the Lambda Calculus] and implements it on a microcontroller better suited to the most mundane of tasks, like running a vending machine or microwave oven. And it sticks the microcontroller in a can that you can connect to your PC using a USB cable.&lt;/blockquote&gt;
&lt;p &gt;
For those that are both language geeks &lt;i &gt;and&lt;/i&gt; hardware geeks...&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/20">Lambda Calculus</category>
 <pubDate>Wed, 06 Feb 2008 16:28:01 -0500</pubDate>
</item>
<item>
 <title>Relating Complexity and Precision in Control Flow Analysis</title>
 <link>http://lambda-the-ultimate.org/node/2647</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.cs.brandeis.edu/~mairson/Papers/icfp07.pdf&quot;&gt;Relating Complexity and Precision in Control Flow Analysis&lt;/a&gt;, David Van Horn and Harry Mairson. ICFP 2007.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We analyze the computational complexity of kCFA, a hierarchy of control flow analyses that determine which functions may be applied at a given call-site. This hierarchy specifies related decision problems, quite apart from any algorithms that may implement their solutions. We identify a simple decision problem answered by this analysis and prove that in the 0CFA case, the problem is complete for polynomial time. The proof is based on a nonstandard, symmetric implementation of Boolean logic within multiplicative linear logic (MLL). We also identify a simpler version of 0CFA related to eta-expansion, and prove that it is complete for logarithmic space, using arguments based on computing paths and permutations.&lt;/p&gt;
&lt;p &gt;For any fixed k &amp;gt; 0, it is known that kCFA (and the analogous decision problem) can be computed in time exponential in the program size. For k = 1, we show that the decision problem is NP-hard, and sketch why this remains true for larger fixed values of k. The proof technique depends on using the approximation of CFA as an essentially nondeterministic computing mechanism, as distinct from the exactness of normalization. When k = n, so that the &quot;depth&quot; of the control flow analysis grows linearly in the program length, we show that the decision problem is complete for exponential time.&lt;/p&gt;
&lt;p &gt;In addition, we sketch how the analysis presented here may be extended naturally to languages with control operators. All of the insights presented give clear examples of how straightforward observations about linearity, and linear logic, may in turn be used to give a greater understanding of functional programming and program analysis.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;There&#039;s ton of really good stuff in here; I was particularly fascinated by the fact that 0-CFA is &lt;em &gt;exact&lt;/em&gt; for multiplicatively linear programs (ie, that use variables at most once), because linearity guarantees that every lambda can flow to at most one use site.  &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/19">Theory</category>
 <pubDate>Fri, 01 Feb 2008 13:47:53 -0500</pubDate>
</item>
<item>
 <title>Call-by-value Termination in the Untyped Lambda-calculus</title>
 <link>http://lambda-the-ultimate.org/node/2598</link>
 <description>&lt;p &gt;&lt;a href=&#039;http://arxiv.org/abs/0801.0882&#039;&gt;From Arxiv:&lt;/a&gt;&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;A fully-automated algorithm is developed able to show that evaluation of a given untyped lambda-expression will terminate under CBV (call-by-value). The ``size-change principle&#039;&#039; from first-order programs is extended to arbitrary untyped lambda-expressions in two steps. The first step suffices to show CBV termination of a single, stand-alone lambda-expression. The second suffices to show CBV termination of any member of a regular set of lambda-expressions, defined by a tree grammar. (A simple example is a minimum function, when applied to arbitrary Church numerals.) The algorithm is sound and proven so in this paper. The Halting Problem&#039;s undecidability implies that any sound algorithm is necessarily incomplete: some lambda-expressions may in fact terminate under CBV evaluation, but not be recognised as terminating.&lt;br &gt;
The intensional power of the termination algorithm is reasonably high. It certifies as terminating many interesting and useful general recursive algorithms including programs with mutual recursion and parameter exchanges, and Colson&#039;s ``minimum&#039;&#039; algorithm. Further, our type-free approach allows use of the Y combinator, and so can identify as terminating a substantial subset of PCF.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;To renew the discussion on &lt;a href=&#039;http://lambda-the-ultimate.org/node/2003&#039;&gt;Total Functional Programming&lt;/a&gt;, this paper is an alternative to &lt;a href=&#039;http://lambda-the-ultimate.org/node/2030&#039;&gt;Termination Checking with Types&lt;/a&gt;.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <pubDate>Tue, 08 Jan 2008 00:29:25 -0500</pubDate>
</item>
<item>
 <title>Theorem proving support in programming language semantics</title>
 <link>http://lambda-the-ultimate.org/node/2582</link>
 <description>&lt;blockquote &gt;&lt;p &gt;
We describe several views of the semantics of a simple programming language as formal documents in the calculus of inductive constructions that can be verified by the Coq proof system. Covered aspects are natural semantics, denotational semantics, axiomatic semantics, and abstract interpretation. Descriptions as recursive functions are also provided whenever suitable, thus yielding a a verification condition generator and a static analyser that can be run inside the theorem prover for use in reflective proofs. Extraction of an interpreter from the denotational semantics is also described. All different aspects are formally proved sound with respect to the natural semantics specification.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;More work on mechanized metatheory with an eye towards naturalness of representation and automation. This seems to me to relate to Adam Chlipala&#039;s work on &lt;a href=&quot;http://lambda-the-ultimate.org/node/2146&quot;&gt;A Certified Type-Preserving Compiler from Lambda Calculus to Assembly Language&lt;/a&gt;, which relies on denotational semantics and proof by reflection, in crucial ways. More generally, it seems to reinforce an important trend in using type-theory-based theorem provers to tackle programming language design from the semantic point of view (see also &lt;a href=&quot;http://lambda-the-ultimate.org/node/1760&quot;&gt;A Very Modal Model of a Modern, Major, General Type System&lt;/a&gt; and &lt;a href=&quot;http://lambda-the-ultimate.org/node/2171&quot;&gt;Verifying Semantic Type Soundness of a Simple Compiler&lt;/a&gt;). I find the trend exciting, but of course I also wonder how far we can practically go with it today, given that the overwhelming majority of the literature, including our beloved &lt;a href=&quot;http://lambda-the-ultimate.org/node/492&quot;&gt;Types and Programming Languages&lt;/a&gt;, is based on &lt;a href=&quot;http://lambda-the-ultimate.org/node/1883&quot;&gt;A Syntactic Approach to Type Soundness&lt;/a&gt;. Even the upcoming &lt;a href=&quot;http://lambda-the-ultimate.org/node/2564&quot;&gt;How to write your next POPL paper in Coq&lt;/a&gt; at POPL &#039;08 centers on the syntactic approach.&lt;/p&gt;
&lt;p &gt;Is the syntactic approach barking up the wrong tree, in the long term? The semantic approach? Both? Neither?&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/20">Lambda Calculus</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <pubDate>Thu, 27 Dec 2007 17:21:42 -0500</pubDate>
</item>
<item>
 <title>Natural Deduction for Intuitionistic Non-Commutative Linear Logic</title>
 <link>http://lambda-the-ultimate.org/node/2523</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://citeseer.ist.psu.edu/polakow99natural.html&quot;&gt;Natural Deduction for Intuitionistic Non-Commutative Linear Logic&lt;/a&gt;, Jeff Polakow and Frank Pfenning. TLCA 1999.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Intuitionistic logic captures functional programming in a logical way, as can be seen from the Curry-Howard isomorphism between constructive proofs and functional programs. However, there are many structural properties of programs that are not captured within the intuitionistic framework, such as resource usage, computational complexity, and sequentiality. Intuitionistic linear logic can be thought of as a refinement of intuitionistic logic in which the resource consumption properties of functions can be expressed internally. Here, we further refine it to allow the expression of sequencing of computations. We achieve this by controlling the use of the structural rule of exchange to arrive at &lt;em &gt;intuitionistic non-commutative linear logic&lt;/em&gt;.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;My earlier post on linguistics reminded me of the Lambek calculus, which is an ordered logic invented in 1958(!) to model how to parse sentences. So I wanted to find a paper on ordered logic (ie, you can&#039;t freely swap the order of hypotheses in a context) and link to that. &lt;/p&gt;</description>
 <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>Mon, 05 Nov 2007 12:08:44 -0500</pubDate>
</item>
<item>
 <title>Gödel, Nagel, minds and machines</title>
 <link>http://lambda-the-ultimate.org/node/2515</link>
 <description>&lt;p &gt; Solomon Feferman. &lt;a href=&quot;http://math.stanford.edu/~feferman/papers/godelnagel.pdf&quot;&gt;Gödel, Nagel, minds and machines.&lt;/a&gt; Ernest Nagel Lecture, Columbia University, Sept. 27, 2007.&lt;br &gt;
&lt;blockquote &gt;&lt;p &gt;
Just fifty years ago, Ernest Nagel and Kurt Goedel became involved in a serious imbroglio about the possible inclusion of Goedel’s original work on incompleteness in the book, &lt;em &gt;Goedel’s Proof&lt;/em&gt;, then being written by Nagel with James R. Newman.  What led to the conflict were some unprecedented demands that Goedel made over the use of his material and his involvement in the contents of the book - demands that resulted in an explosive reaction on Nagel’s part.  In the end the proposal came to naught.  But the story is of interest because of what was basically at issue, namely their provocative related but contrasting views on the possible significance of Goedel’s theorems for minds vs. machines in the development of mathematics.&lt;br &gt;
&lt;/blockquote&gt;
&lt;p &gt;
This is not directly PLT related, and more philosophical than what we usually discuss on LtU, but I think it will be of interest to some members of the community.&lt;p &gt;
While the historical details are interesting, I am not sure I agree with the analysis. It would be interesting to here what others make of this.&lt;p &gt;
To make this item slightly more relevant to LtU, let me point out that both the LC and category theory are mentioned (although they are really discussed only in the references).&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <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>
 <pubDate>Thu, 25 Oct 2007 19:46:41 -0400</pubDate>
</item>
<item>
 <title>On One-Pass CPS Transformations</title>
 <link>http://lambda-the-ultimate.org/node/2507</link>
 <description>&lt;p &gt;Olivier Danvy, Kevin Millikin and Lasse R. Nielsen. &lt;a href=&quot;http://www.brics.dk/RS/07/6/index.html&quot;&gt;On One-Pass CPS Transformations&lt;/a&gt;. March 2007.&lt;br &gt;
&lt;blockquote &gt;&lt;p &gt;
We bridge two distinct approaches to one-pass CPS transformations, i.e., CPS transformations that reduce administrative redexes at transformation time instead of in a post-processing phase. One approach is compositional and higher-order, and is independently due to Appel, Danvy and Filinski, and Wand, building on Plotkin&#039;s seminal work. The other is non-compositional and based on a reduction semantics for the lambda-calculus, and is due to Sabry and Felleisen. To relate the two approaches, we use three tools: Reynolds&#039;s defunctionalization and its left inverse, refunctionalization; a special case of fold-unfold fusion due to Ohori and Sasano, fixed-point promotion; and an implementation technique for reduction semantics due to Danvy and Nielsen, refocusing.&lt;/p&gt;
&lt;p &gt;This work is directly applicable to transforming programs into monadic normal form.&lt;/blockquote&gt;
&lt;p &gt;
Also in JFP 17:793-812 (2007).&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <pubDate>Tue, 23 Oct 2007 01:59:11 -0400</pubDate>
</item>
<item>
 <title>Binary Lambda Calculus and Combinatory Logic</title>
 <link>http://lambda-the-ultimate.org/node/2458</link>
 <description>&lt;p &gt;While Anton was waxing about &lt;a href=&#039;http://programming.reddit.com/info/2q0uv/comments&#039;&gt;Church &amp;amp; Turing&lt;/a&gt;, I figured that &lt;a href=&quot;http://en.wikipedia.org/wiki/Occam&amp;#039;s_razor&quot;&gt;Occam&#039;s Razor&lt;/a&gt; would be the type of proof one would postulate when giving the nod to Lambda Calculus over Universal Turing Machines.  This leads inexorably to the question of what is the smallest (as measured in binary bits) Turing Machine that can possibly be constructed.  John Tromp provides an answer to this question in his always fun &lt;a href=&#039;http://homepages.cwi.nl/~tromp/cl/cl.html&#039;&gt;Lambda Calculus and Combinatory Logic Playground&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Pictured you can see the 210 bit binary lambda calculus self-interpreter, and the 272 bit binary combinatory logic self-interpreter.  Both are explained in detail in my latest paper available in &lt;a href=&quot;http://homepages.cwi.nl/~tromp/cl/LC.ps&quot;&gt;PostScript&lt;/a&gt; and &lt;a href=&quot;http://homepages.cwi.nl/~tromp/cl/LC.pdf&quot;&gt;PDF&lt;/a&gt;. This design of a minimalistic universal computer was motivated by my desire to come up with a concrete definition of Kolmogorov Complexity, which studies randomness of individual objects. All ideas in the paper have been &lt;a href=&quot;http://homepages.cwi.nl/~tromp/cl/Lambda.lhs&quot;&gt;implemented&lt;/a&gt;  in the the wonderfully elegant Haskell language, which is basically pure typed lambda calculus with lots of syntactic sugar on top.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Interestingly, the version based on the Lambda Calculus is smaller than the one on Combinators.  A statement I found of interest in the paper about PL&#039;s:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Although information content may seem to be highly dependent on choice of programming language, the notion is actually invariant up to an additive constant.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Not sure if that statement means that PL research is ultimately doomed.  :-)&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/20">Lambda Calculus</category>
 <pubDate>Tue, 18 Sep 2007 16:10:33 -0400</pubDate>
</item>
<item>
 <title>Compiling with Continuations, Continued</title>
 <link>http://lambda-the-ultimate.org/node/2406</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://research.microsoft.com/~akenn/sml/CompilingWithContinuationsContinued.pdf&quot;&gt;Compiling with Continuations, Continued&lt;/a&gt;, Andrew Kennedy. ICFP 2007.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We present a series of CPS-based intermediate languages suitable for functional language compilation, arguing that they have practical benefits over direct-style languages based on A-normal form (ANF) or monads. Inlining of functions demonstrates the benefits most clearly: in ANF-based languages, inlining involves a renormalization step that rearranges let expressions and possibly introduces a new ‘join point’ function, and in monadic languages, commuting conversions must be applied; in contrast, inlining in our CPS language is a simple substitution of variables for variables.&lt;/p&gt;
&lt;p &gt;We present a contification transformation implemented by simple rewrites on the intermediate language. Exceptions are modelled using so-called ‘double-barrelled’ CPS. Subtyping on exception constructors then gives a very straightforward effect analysis for exceptions. We also show how a graph-based representation of CPS terms can be implemented extremely efficiently, with linear-time term simplification.
&lt;/p&gt;&lt;/blockquote&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>
 <pubDate>Fri, 17 Aug 2007 17:15:29 -0400</pubDate>
</item>
<item>
 <title>Analyzing the Environment Structure ofHigher-Order Languages using Frame Strings</title>
 <link>http://lambda-the-ultimate.org/node/2404</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://matt.might.net/papers/might2007dcfa.pdf&quot;&gt;Analyzing the Environment Structure of Higher-Order Languages using Frame Strings&lt;/a&gt;, Matthew Might and Olin Shivers. 2007. &lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Reasoning about program behaviour in programming languages based on the lambda-calculus requires reasoning in a unified way about control, data and environment structure. Previous analysis work has done an inadequate job on the environment component of this task. We develop a new analytic framework, Delta-CFA, which is based on a new abstraction: frame strings, an enriched variant of procedure strings that can be used to model both control flow and environment allocation. This abstraction enables new environment-sensitive analyses and transformations that have not been previously attainable. We state the critical theorems needed to establish correctness of the entire technology suite, with their proofs.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Even if you&#039;re not interested in flow analysis of functional languages, the preface to this paper is very enjoyable reading. (If you are interested in flow analysis, the whole thing is enjoyable reading. I want a couple of weeks to go through this paper in detail.)  &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/29">Semantics</category>
 <pubDate>Thu, 16 Aug 2007 12:23:15 -0400</pubDate>
</item>
<item>
 <title>Lambda: The Semantics Tool</title>
 <link>http://lambda-the-ultimate.org/node/2360</link>
 <description>&lt;blockquote &gt;&lt;p &gt;
&lt;a href=&quot;http://www.ling.upenn.edu/lambda/&quot;&gt;Lambda&lt;/a&gt; is an interactive, graphical, pedagogical computer program that helps students of formal semantics practice the typed lambda calculus.&lt;br &gt;
&lt;/blockquote&gt;
&lt;p &gt;
We discussed how the LC is used in linguistics in the past (check the archives). This tool may be useful even for those not interested in this angle, even though that&#039;s the intended use of the software.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <pubDate>Sun, 22 Jul 2007 13:56:22 -0400</pubDate>
</item>
<item>
 <title>Lambda Animator</title>
 <link>http://lambda-the-ultimate.org/node/2343</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://thyer.name/lambda-animator/&quot;&gt;Lambda Animator&lt;/a&gt; from Mike Thyer is a tool for displaying and experimenting with alternate reduction strategies in the LC. The tool can use a number of reduction strategies, including completely lazy evaluation. &lt;p &gt;
The tool can be invoked in several different modes (via JWS or as an applet), and contains many examples, and the documentation provides clear definitions of the sometime confusing terminology in the field.&lt;p &gt;
Notice that the &quot;step&quot; and &quot;run&quot; buttons only work when rendering new graphs, which only works if you are running in trusted mode and have Graphviz installed. Otherwise you&#039;ll have to use the the up/down cursor keys or the scroll bar to review already rendered graphs (which exist for all the examples).  &lt;p &gt;
The site list relevant papers and dissertations.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/20">Lambda Calculus</category>
 <pubDate>Wed, 11 Jul 2007 05:31:17 -0400</pubDate>
</item>
</channel>
</rss>
