<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://lambda-the-ultimate.org">
<channel>
 <title>Lambda the Ultimate - Theory</title>
 <link>http://lambda-the-ultimate.org/taxonomy/term/19/0</link>
 <description></description>
 <language>en</language>
<item>
 <title>Seven Myths of Formal Methods Revisited</title>
 <link>http://lambda-the-ultimate.org/node/4425</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.5280&quot;&gt;Software Engineering with Formal Methods: The Development of a Storm Surge Barrier Control System - Seven Myths of Formal Methods Revisited (2001)&lt;/a&gt;, by Jan Tretmans, Klaas Wijbrans, Michel Chaudron:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Bos is the software system which controls and operates the storm surge barrier in the Nieuwe Waterweg near Rotterdam. It is a complex, safety-critical system of average size, which was developed by CMG Den Haag B.V., commissioned by Rijkswaterstaat (RWS) – the Dutch Ministry of Transport, Public Works and Water Management. It was completed in October 1998 on time and within budget.&lt;/p&gt;
&lt;p &gt;CMG used formal methods in the development of the Bos software. This paper discusses the experiences obtained from their use. Some people claim that the use of formal methods helps in developing correct and reliable software, others claim that formal methods are useless and unworkable. Some of these claims have almost become myths. A number of these myths are described and discussed in a famous article: Seven Myths of Formal Methods [Hal90]. The experiences obtained from using formal methods for the development of Bos will be discussed on the basis of this article. We will discuss to what extent these myths are true for the Bos project.&lt;/p&gt;
&lt;p &gt;The data for this survey were collected by means of interviews with software engineers working on the Bos project. These include the project manager, designers, implementers and testers, people who participated from the beginning in 1995 until the end in 1998 as well as engineers who only participated in the implementation phase, and engineers with and without previous, large-scale software engineering experience.&lt;/p&gt;
&lt;p &gt;This paper concentrates on the experiences of the software engineers with formal methods. These experiences, placed in the context of the seven myths, are described in section 3. This paper does not discuss technical details about the particular formal methods used or the way they were used; see [Kar97, Kar98] for these aspects. Moreover, formal methods were only one technique used in the development of Bos. The overall engineering approach and the way diﬀerent methods and techniques were combined to assure the required safetycritical quality, are described [WBG98, WB98]. Testing in Bos  is described in more detail in [GWT98], while [CTW99] will give a more systematic analysis of the results of the interviews&lt;br &gt;
with the developers.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Discussion of formal methods and verification has come up &lt;a href=&quot;http://lambda-the-ultimate.org/node/2783&quot;&gt;a few times here on LtU&lt;/a&gt;. In line with the recent discussions on the need for more empirical data in our field, this was an interesting case study on the use of formal methods. The seven myths of formal methods are reviewed in light of a real project:&lt;/p&gt;
&lt;ol &gt;
&lt;li &gt;Myth 1: Formal methods can guarantee that software is perfect&lt;/li&gt;
&lt;li &gt;Myth 2: Formal methods are all about program proving&lt;/li&gt;
&lt;li &gt;Myth 3: Formal methods are only useful for safety-critical system&lt;/li&gt;
&lt;li &gt;Myth 4: Formal methods require highly trained mathematicians&lt;/li&gt;
&lt;li &gt;Myth 5: Formal methods increase the cost of developmen&lt;/li&gt;
&lt;li &gt;Myth 6: Formal methods are unacceptable to users&lt;/li&gt;
&lt;li &gt;Myth 7: Formal methods are not used on real, large-scale software&lt;/li&gt;
&lt;/ol&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/8">Implementation</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/17">Software Engineering</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Tue, 27 Dec 2011 11:19:15 -0500</pubDate>
</item>
<item>
 <title>Extensible Programming with First-Class Cases</title>
 <link>http://lambda-the-ultimate.org/node/4394</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://ttic.uchicago.edu/~wchae/files/icfp06.pdf&quot;&gt;Extensible Programming with First-Class Cases&lt;/a&gt;, by Matthias Blume, Umut A. Acar, and Wonseok Chae:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;We present language mechanisms for polymorphic, extensible records and their exact dual, polymorphic sums with extensible first-class cases. These features make it possible to easily extend existing code with new cases. In fact, such extensions do not require any changes to code that adheres to a particular programming style. Using that style, individual extensions can be written independently and later be composed to form larger components. These language mechanisms provide a solution to the expression problem.&lt;/p&gt;
&lt;p &gt;We study the proposed mechanisms in the context of an implicitly typed, purely functional language PolyR. We give a type system for the language and provide rules for a 2-phase transformation: first into an explicitly typed λ-calculus with record polymorphism, and finally to efficient index-passing code. The first phase eliminates sums and cases by taking advantage of the duality with records.&lt;/p&gt;
&lt;p &gt;We implement a version of PolyR extended with imperative features and pattern matching—we call this language MLPolyR. Programs in MLPolyR require no type annotations—the implementation employs a reconstruction algorithm to infer all types. The compiler generates machine code (currently for PowerPC) and optimizes the representation of sums by eliminating closures generated by the dual construction.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;This is an elegant solution to the expression problem for languages with pattern matching. This paper &lt;a href=&quot;http://lambda-the-ultimate.org/node/3338&quot;&gt;was posted twice in LtU comments&lt;/a&gt;, but it definitely deserves its own story. Previous solutions to the exression problem are rather more involved, like &lt;a href=&quot;http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.8079&quot;&gt;Garrigue&#039;s use of recursion and polymorphic variants&lt;/a&gt;, because they lack support for extensible records which makes this solution so elegant.&lt;/p&gt;
&lt;p &gt;Extensible records and first-class cases unify object-oriented and functional paradigms on a deeper level, since they enable first-class messages to be directly encoded. Add a sensible system for dynamics, and I argue you have most of the power people claim of dynamic languages without sacrificing the safety of static typing.&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/17">Software Engineering</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/21">Type Theory</category>
 <pubDate>Sun, 30 Oct 2011 17:41:17 -0400</pubDate>
</item>
<item>
 <title>Foundations of Inference</title>
 <link>http://lambda-the-ultimate.org/node/4393</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://arxiv.org/abs/1008.4831&quot;&gt;Foundations of Inference&lt;/a&gt;, Kevin H. Knuth, John Skilling, arXiv:1008.4831v1 [math.PR]&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We present a foundation for inference that unites and significantly extends the approaches of Kolmogorov and Cox. Our approach is based on quantifying finite lattices of logical statements in a way that satisfies general lattice symmetries. With other applications in mind, our derivations assume minimal symmetries, relying on neither complementarity nor continuity or differentiability. Each relevant symmetry corresponds to an axiom of quantification, and these axioms are used to derive a unique set of rules governing quantification of the lattice. These rules form the familiar probability calculus. We also derive a unique quantification of divergence and information. Taken together these results form a simple and clear foundation for the quantification of inference.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;For those of us who find ourselves compelled by the view of probability as a generalization of logic that is isomorphic to (algorithmic, as if there were any other kind) information theory, here is some recent i-dotting and t-crossing. The connection to Curry-Howard or, if you prefer, Krivine&#039;s classical realizability is something I hope to explore in the near future.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Sun, 30 Oct 2011 13:52:33 -0400</pubDate>
</item>
<item>
 <title>A Semantic Model for Graphical User Interfaces</title>
 <link>http://lambda-the-ultimate.org/node/4352</link>
 <description>&lt;p &gt;Nick Benton and Neel Krishnaswami, ICFP&#039;11, &lt;A href=&quot;http://www.cs.cmu.edu/~neelk/icfp11-krishnaswami-benton.pdf&quot;&gt;A Semantic Model for Graphical User Interfaces&lt;/A&gt;:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
We give a denotational model for graphical user interface (GUI) programming using the Cartesian closed category of ultrametric spaces. [..] We capture the arbitrariness of user input [..] [by a nondeterminism] “powerspace” monad.&lt;/p&gt;
&lt;p &gt;Algebras for the powerspace monad yield a model of intuitionistic linear logic, which we exploit in the definition of a mixed linear/non-linear domain-specific language for writing GUI programs. The non-linear part of the language is used for writing reactive stream-processing functions whilst the linear sublanguage naturally captures the generativity and usage constraints on the various linear objects in GUIs, such as the elements of a DOM or scene graph.&lt;/p&gt;
&lt;p &gt;We have implemented this DSL as an extension to OCaml, and give examples demonstrating that programs in this style can be short and readable.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;This is an application of their (more squiggly) LICS&#039;11 submission, &lt;A href=&quot;http://www.cs.cmu.edu/~neelk/frp-lics11.pdf&quot;&gt;Ultrametric Semantics of Reactive Programs&lt;/A&gt;. In both these cases, I find appealing the fact the semantic model led to a type system and a language that was tricky to find.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/24">DSL</category>
 <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/10">Paradigms</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Sat, 10 Sep 2011 16:25:56 -0400</pubDate>
</item>
<item>
 <title>A Monadic Framework for Delimited Continuations</title>
 <link>http://lambda-the-ultimate.org/node/4334</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR615&quot;&gt;A Monadic Framework for Delimited Continuations&lt;/a&gt; (&lt;a href=&quot;http://www.cs.indiana.edu/pub/techreports/TR615.pdf&quot;&gt;PDF&lt;/a&gt;), R. Kent Dybvig, Simon Peyton Jones, Amr Sabry. TR, June 2005.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Delimited continuations are more expressive than traditional abortive continuations and they apparently seem to require a framework beyond traditional continuation-passing style (CPS). We show that this is not the case: standard CPS is sufficient to explain the common control operators for delimited continuations. We demonstrate this fact and present an implementation as a Scheme library. We then investigate a typed account of delimited continuations that makes explicit where control effects can occur. This results in a monadic framework for typed and encapsulated delimited continuations which we design and implement as a Haskell library.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;A fascinating paper about delimited control. I&#039;m very much a newbie to delimited control, but this paper has been enormously helpful - despite the title. ;)&lt;/p&gt;
&lt;p &gt;The basic idea of the paper is to represent the execution context as a sequence containing prompts (control delimiters) and the (partial) continuations between prompts. This model is formalized with an operational semantics, which was insightful even though it&#039;s the first operational semantics I&#039;ve studied.&lt;/p&gt;
&lt;p &gt;The authors then present an implementation of the model in terms of call/cc in Scheme. The basic idea here is to always perform user code after aborting to a context near the bottom of the stack, just above a call to an underflow function - this means that even though we use undelimited call/cc, we only ever capture our (small, partial) execution context.  The whole execution context (the &quot;metacontinuation&quot;) is maintained as a sequence &lt;em &gt;data structure&lt;/em&gt; in a global variable (basically, a list containing prompts and Scheme continuations).  The underflow function destructures the metacontinuation, and executes (returns to) the partial continuations stored in it.  Pushing a prompt adds a delimiter to the metacontinuation, capturing a delimited continuation splits the metacontinuation at a delimiter, and composing a continuation appends to the metacontinuation.&lt;/p&gt;
&lt;p &gt;I haven&#039;t even gotten to the later parts of the paper yet, but this model and the Scheme implementation alone is worth a look.&lt;/p&gt;
&lt;p &gt;(The paper seems to be a reworked version of A Monadic Framework for Subcontinuations,  &lt;a href=&quot;http://lambda-the-ultimate.org/node/792&quot;&gt;discussed previously&lt;/a&gt;.)&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/19">Theory</category>
 <pubDate>Wed, 24 Aug 2011 14:00:02 -0400</pubDate>
</item>
<item>
 <title>Levy:  a Toy Call-by-Push-Value Language</title>
 <link>http://lambda-the-ultimate.org/node/4314</link>
 <description>&lt;p &gt;Andrej Bauer&#039;s &lt;A href=&#039;http://math.andrej.com/&#039;&gt;blog&lt;/A&gt; contains the &lt;A href=&#039;http://math.andrej.com/?s=PL+Zoo&#039;&gt;PL Zoo&lt;/A&gt; project. In particular, the &lt;A href=&#039;http://math.andrej.com/2008/11/23/a-toy-call-by-push-value-language/&#039;&gt;Levy&lt;/A&gt; language, a toy implementation of Paul Levy&#039;s &lt;A href=&#039;http://lambda-the-ultimate.org/node/1975&#039;&gt;CBPV&lt;/A&gt; in OCaml. &lt;/p&gt;
&lt;p &gt;If you&#039;re curious about CBPV, this implementation might be a nice accompaniment to the &lt;A href=&#039;http://portal.acm.org/citation.cfm?id=984044&#039;&gt;book&lt;/A&gt;, or simply a hands on way to check it out.&lt;/p&gt;
&lt;p &gt;It looks like an implementation of CBPV without sum and product types, with complex values, and without effects. I guess a more hands-on way to get to grips with CBPV would be to implement any of these missing features.&lt;/p&gt;
&lt;p &gt;The posts are are 3 years old, but I&#039;ve only just noticed them. The PL Zoo project was &lt;A href=&#039;http://lambda-the-ultimate.org/node/2815#comment-42266&#039;&gt;briefly mentioned&lt;/A&gt; here.&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/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/10">Paradigms</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/18">Teaching &amp; Learning</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Thu, 14 Jul 2011 14:57:09 -0400</pubDate>
</item>
<item>
 <title>Imperative Programs as Proofs via Game Semantics </title>
 <link>http://lambda-the-ultimate.org/node/4253</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://people.bath.ac.uk/mdc25/lics11.pdf&quot;&gt;Imperative Programs as Proofs via Game Semantics&lt;/a&gt;, Martin Churchill, James Laird and Guy McCusker. To appear at LICS 2011.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Game semantics extends the Curry-Howard isomorphism to a three-way correspondence: proofs, programs, strategies. But the universe of strategies goes beyond intuitionistic logics and lambda calculus, to capture stateful programs. In this paper we describe a logical counterpart to this extension, in which proofs denote such strategies. We can embed intuitionistic ﬁrst-order linear logic into this system, as well as an imperative total programming language. The logic makes explicit use of the fact that in the game semantics the exponential can be expressed as a ﬁnal coalgebra. We establish a full completeness theorem for our logic, showing that every bounded strategy is the denotation of a proof.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;This paper increases the importance of gaining a more-than-casual understanding of game semantics for me, since it combines two of my favorite things: polarized type theories and imperative higher-order programs.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/29">Semantics</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Wed, 13 Apr 2011 05:28:25 -0400</pubDate>
</item>
<item>
 <title>Functor is to Lens as Applicative is to Biplate: Introducing Multiplate</title>
 <link>http://lambda-the-ultimate.org/node/4233</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://front.math.ucdavis.edu/1103.2841&quot;&gt;Functor is to Lens as Applicative is to Biplate: Introducing Multiplate&lt;/a&gt; is an interesting paper by Russell O&#039;Connor which shows that certain types are isomorphic to quantification over certain type classes.  This isomorphism then naturally leads to a generalization of Uniplate/Compos into Multiplate, which allows for rather generic traversals.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;The BiplateType datatype defined in the Uniplate library is similar to a lens (a.k.a. a functional reference). This paper proves that Biplate generalizes lens similarly to how applicative functor generalizes functor. This paper gives an alternative definition of BiplateType using a nested data type that better captures the invariants for Biplates than Uniplate&#039;s original definition. In previous work, van Laarhoven conjectures an isomorphism between this nested data type and a data type found in Compos library. This paper complete his proof of the isomorphism by using free theorems for types polymorphic over applicative functors. This result means that, morally speaking, Compos and Uniplate use isomorphic representations for their core data type for generic traversals of simple recursive data types. For mutually recursive data types, Compos and Uniplate providing two different extensions to this common core functionality. Compos requires the user to rewrite a mutually recursive data type as a GADT, while Uniplate&#039;s Biplate class, is less powerful but only requires multiparameter type classes and does not require rewriting one&#039;s data type. This paper proposes a third extension to support mutually recursive datatypes that is as powerful as Compos, as easy to use as Biplate, and more portable than both of them. This proposal, called Multiplate, only requires rank 3 polymorphism.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;(Full disclosure: Russell is a post-doc at McMaster, working with me and Bill Farmer.  While trying to figure out how to make certain repetitive traversals of &lt;a href=&quot;http://www.cas.mcmaster.ca/research/mathscheme/&quot;&gt;MathScheme&lt;/a&gt; ASTs into a generic framework, he &#039;stumbled upon&#039; multiplate, and then kept pursuing the ideas, with the &lt;a href=&quot;http://hackage.haskell.org/package/multiplate&quot;&gt;multiplate package&lt;/a&gt; and this nice bit of theory as the end result.)&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Wed, 16 Mar 2011 19:16:37 -0400</pubDate>
</item>
<item>
 <title>Tractatus Digito-Philosophicus</title>
 <link>http://lambda-the-ultimate.org/node/4206</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.hxa.name/articles/content/tractatus-digito-philosophicus_hxa7241_2010.html&quot;&gt;Tractatus Digito-Philosophicus&lt;/a&gt;, part of the project &lt;a href=&quot;http://www.hxa.name/notes/note-hxa7241-20110219T1113Z.html&quot;&gt;Wittgenstein for programmers&lt;/a&gt; by Harrison Ainsworth (whose &lt;a href=&quot;http://www.hxa.name/notes/&quot;&gt;blog&lt;/a&gt; is very much recommended to LtUers).&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
This is a somewhat odd venture: a translation of Wittgenstein&#039;s Tractatus into the domain of software development.&lt;/p&gt;
&lt;p &gt;The software intellect – its basic conceptual forms – is rooted in the early 20th century, the 1910s, 1920s, 1930s. That is where the work of Church and Turing, lambda calculus and computability, comes from. And it is also the time of the Vienna Circle, logical positivism, and Wittgenstein&#039;s early work, the ‘Tractatus Logico-Philosophicus’.&lt;/p&gt;
&lt;p &gt;One might notice one day that software seems pointedly related to its original philosophical contemporaries. It is fundamentally a logical construction. It is like a Wittgensteinian logical proposition, but instead of describing the world, software constructs the imagination. There is a clear isomorphism. All terms related to describing map to terms related to constructing, and similarly for world and imagination. It seems a simple transformation will take Wittgenstein to software.&lt;/p&gt;
&lt;p &gt;So an interesting project emerges: translate the Tractatus into software terms! The result is sometimes obscure, but sometimes clearer than the original, and most is (still) quite odd and intriguing (which is perhaps the main virtue anyway) . . .&lt;/p&gt;
&lt;p &gt;(So far it is only partial and unfinished.)
&lt;/p&gt;&lt;/blockquote&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/5">Fun</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Sat, 19 Feb 2011 12:44:40 -0500</pubDate>
</item>
<item>
 <title>The Habit Programming Language: The Revised Preliminary Report</title>
 <link>http://lambda-the-ultimate.org/node/4205</link>
 <description>&lt;p &gt;Habit is a systems programming dialect of Haskell from the &lt;a href=&quot;http://hasp.cs.pdx.edu/&quot;&gt;High-Assurance Systems Programming (HASP)&lt;/a&gt; project at Portland State University. From &lt;a href=&quot;http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf&quot;&gt;The Habit Programming Language: The Revised Preliminary Report&lt;/a&gt;&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;This report presents a preliminary design for the programming language Habit, a dialect of Haskell that supports the development of high quality systems software. The primary commitments of the design are as follows:&lt;/p&gt;
&lt;p &gt;* Systems programming: Unlike Haskell, which was intended to serve as a general purpose functional programming language, the design of Habit focusses on features that are needed in systems software development. These priorities are reﬂected fairly directly in the new features that Habit provides for describing bit-level and memory-based data representations, the introduction of new syntactic extensions to facilitate monadic programming, and, most  signiﬁcantly, the adoption of a call-by-value semantics to improve predictability of execution. The emphasis on systems programming also impacts the design in less direct ways, including assumptions about the expected use of whole program compilation and optimization strategies in a practical Habit implementation.&lt;/p&gt;
&lt;p &gt;* High assurance: Although most details of Haskell’s semantics have been formalized at some point in the research literature, there is no consolidated formal description of the whole language. There are also known differences in semantics, particularly with respect to operational behavior, between different Haskell implementations in areas where the Haskell report provides no guidance. Although it is not addressed in the current report, a high-priority for Habit is to provide a full, formal semantics for the complete language that can be used as a foundation for reasoning and formal veriﬁcation, a mechanism for ensuring consistency between implementations, and a basis for reliably predicting details about memory allocation, asymptotic behavior, and resource utilization.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;HASP has a couple of &lt;a href=&quot;http://lambda-the-ultimate.org/node/4204&quot;&gt;postdoc positions&lt;/a&gt; open to help with Habit.&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/17">Software Engineering</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Fri, 18 Feb 2011 11:06:41 -0500</pubDate>
</item>
<item>
 <title>Invertible Syntax Descriptions: Unifying Parsing and Pretty Printing</title>
 <link>http://lambda-the-ultimate.org/node/4191</link>
 <description>&lt;p &gt;In &lt;a href=&quot;http://www.informatik.uni-marburg.de/~rendel/unparse/rendel10invertible.pdf&quot;&gt;Invertible Syntax Descriptions: Unifying Parsing and Pretty Printing&lt;/a&gt;, Rendel Tillmann and Klaus Ostermann at the University of Marburg, Germany apply the &quot;don&#039;t repeat yourself&quot; principle to parsers and pretty printers.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Parsers and pretty-printers for a language are often quite similar, yet both are typically implemented separately, leading to redundancy and potential inconsistency. We propose a new interface of syntactic descriptions, with which both parser and pretty-printer can be described as a single program. Whether a syntactic description is used as a parser or as a pretty-printer is determined by the implementation of the interface. Syntactic descriptions enable programmers to describe the connection between concrete and abstract syntax once and for all, and use these descriptions for parsing or pretty-printing as needed. We also discuss the generalization of our programming technique towards an algebra of partial isomorphisms.&lt;/p&gt;&lt;/blockquote&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/8">Implementation</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Wed, 26 Jan 2011 19:21:21 -0500</pubDate>
</item>
<item>
 <title>Concurrent Pattern Calculus</title>
 <link>http://lambda-the-ultimate.org/node/4189</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.dsi.uniroma1.it/~gorla/papers/cpc-long.pdf&quot;&gt;Concurrent Pattern Calculus&lt;/a&gt; by Thomas Given-Wilson, Daniele Gorla, and Barry Jay:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Concurrent pattern calculus drives interaction between processes by comparing data structures, just as sequential pattern calculus drives computation. By generalising from pattern matching to pattern unification, interaction becomes symmetrical, with information flowing in both directions. This provides a natural language for describing any form of exchange or trade. Many popular process calculi can be encoded in concurrent pattern calculi.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Barry Jay&#039;s &lt;a href=&quot;http://lambda-the-ultimate.org/node/1678&quot;&gt;Pattern Calculus&lt;/a&gt; has been discussed a &lt;a href=&quot;http://lambda-the-ultimate.org/node/3695&quot;&gt;few times here before&lt;/a&gt;. I&#039;ve always been impressed with the pattern calculus&#039; expressive power for computing over arbitrary structure. The pattern calculus supports new forms of polymorphism, which he termed &quot;path polymorphism&quot; and &quot;pattern polymorphism&quot;, which are difficult to provide in other calculi. The closest I can think of would be a compiler-provided generalized fold over any user-defined structure.&lt;/p&gt;
&lt;p &gt;This work extends the pattern calculus to the concurrent setting by adding constructs for parallel composition, name restriction and replication, and argues convincingly for its greater expressiveness as compared to other concurrent calculi. He addresses some of the obvious concerns for symmetric information flow of the unification operation.&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/13">Logic/Declarative</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/16">Parallel/Distributed</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Mon, 24 Jan 2011 22:19:55 -0500</pubDate>
</item>
<item>
 <title>Parametric Prediction of Heap Memory Requirements</title>
 <link>http://lambda-the-ultimate.org/node/4183</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.144.7116&quot;&gt;Parametric Prediction of Heap Memory Requirements&lt;/a&gt;, by Victor Braberman, Federico Fernandez, Diego Garbervetsky, Sergio Yovine:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;This work presents a technique to compute symbolic polynomial approximations of the amount of dynamic memory required to safely execute a method without running out of memory, for Java-like imperative programs. We consider object allocations and deallocations made by the method and the methods it transitively calls. More precisely, given an initial conﬁguration of the stack and the heap, the peak memory consumption is the maximum space occupied by newly created objects in all states along a run from it. We over-approximate the peak memory consumption using a scoped-memory management where objects are organized in regions associated with the lifetime of methods. We model the problem of computing the maximum memory occupied by any region conﬁguration as a parametric polynomial optimization problem over a polyhedral domain and resort to Bernstein basis to solve it. We apply the developed tool to several benchmarks.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;We&#039;ve briefly discussed analyses to predict heap usage here on LtU, but I can&#039;t seem to find them. Anyone with a reference handy, please post in the comments!&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/14">OOP</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Sat, 15 Jan 2011 14:24:29 -0500</pubDate>
</item>
<item>
 <title>Automatic Staged Compilation</title>
 <link>http://lambda-the-ultimate.org/node/4151</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.95.6636&quot;&gt;Automatic Staged Compilation&lt;/a&gt;, doctoral dissertation of Matthai Philipose:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;[...] The past few years have seen the emergence of staged optimization, which produces run-time optimizations that often have much lower run-time overhead than traditional optimizers, yet do not sacrifice any of their functionality. The key to the technique is a method, called staging, to transfer optimization overhead to static compile time from run time. Unfortunately, developing staged variants of individual optimizations has been highly specialized, labor-intensive work; staging pipelines of optimizations even more so.&lt;/p&gt;
&lt;p &gt;This dissertation presents a system called the Staged Compilation Framework (SCF), which automatically stages entire pipelines of compiler optimizations at arguably little additional engineering cost beyond building the slower traditional version of the pipeline. SCF harnesses two powerful but traditionally difficult-to-use techniques, partial evaluation and dead-store elimination, to achieve staging. An implementation of SCF shows that staged compilation can speed up pipelines of classical compiler optimizations by up to an order of magnitude, and more commonly by a factor of 4.5 to 5.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;I haven&#039;t read through it all yet, but after a cursory skim it certainly looks interesting.&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/19">Theory</category>
 <pubDate>Mon, 29 Nov 2010 14:36:44 -0500</pubDate>
</item>
<item>
 <title>Yacc is dead</title>
 <link>http://lambda-the-ultimate.org/node/4148</link>
 <description>&lt;p &gt;In &lt;a href=&quot;http://arxiv.org/abs/1010.5023&quot;&gt;Yacc is dead&lt;/a&gt; (2010) Matthew Might and David Darais of the University of Utah, Salt Lake City...&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;present two novel approaches to parsing context-free languages. The first approach is based on an extension of Brzozowski’s derivative from regular expressions to context-free grammars. The second approach is based on a generalization of the derivative to parser combinators. The payoff of these techniques is a small (less than 250 lines of code), easy-to-implement parsing library capable of parsing arbitrary context-free grammars into lazy parse forests. Implementations for both Scala and Haskell are provided. Preliminary experiments with S-Expressions parsed millions of tokens per second, which suggests this technique is efficient enough for use in practice.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;It seems every problem in computer science can be solved with either one more level of indirection or a derivative.&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/19">Theory</category>
 <pubDate>Sun, 28 Nov 2010 22:48:46 -0500</pubDate>
</item>
</channel>
</rss>

