<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://lambda-the-ultimate.org">
<channel>
 <title>Lambda the Ultimate - Programming Languages Weblog</title>
 <link>http://lambda-the-ultimate.org</link>
 <description>Programming languages news, articles and discussion</description>
 <language>en</language>
<item>
 <title>Modern dynamic linking infrastructure for PLT</title>
 <link>http://lambda-the-ultimate.org/node/3474</link>
 <description>&lt;p &gt;Given that &lt;a href=&quot;http://www.paulgraham.com/arcll1.html&quot;&gt;Unix won&lt;/a&gt;, I think it&#039;s interesting that dynamic languages make very little use of the dynamic linking and loading infrastructure provided by modern free Unixes such as Linux and the BSDs.&lt;/p&gt;
&lt;p &gt;Most dynamic PLs opt to implement &quot;dynamism&quot; (i.e. redefining stuff, loading code at runtime) with application-specific data structures (e.g. Lisp: red-black trees for uniquifying symbols, function pointers and &lt;a href=&quot;http://groups.google.com/group/comp.lang.lisp/msg/96d32a463068044e&quot;&gt;indirect function calls&lt;/a&gt;), and they do so solely at runtime (mostly using interpreters and JITs, although Scheme, one of the most advanced dynamic languages, is increasingly illuminating the possibilities of static, independent compilation of dynamic programs). &lt;/p&gt;
&lt;p &gt;(Metaprogramming at runtime is perilous, as it is easy to mix up &lt;a href=&quot;http://www.readscheme.org/modules/&quot;&gt;phase distinctions&lt;/a&gt;, something we can expect newer dynamic programming languages to discover in a decade (of course we don&#039;t know which decade.))&lt;/p&gt;
&lt;p &gt;&lt;i &gt;Link-time&lt;/i&gt; is mostly ignored.  And yet, under Linux with its heavy use of shared objects, one cannot even &lt;a href=&quot;http://linux.die.net/man/2/execve&quot;&gt;start a single program&lt;/a&gt; without invoking the dynamic linker.&lt;/p&gt;
&lt;p &gt;But some people, &lt;a href=&quot;http://www.airs.com/blog/archives/date/2007/08/page/2/&quot;&gt;even some computer programmers&lt;/a&gt;, don&#039;t know how linkers work and what they do. Basically, a modern linking file format, such as ELF, is a declarative way to construct the memory image of a running process, with lots of features for dynamic customization of the image construction process (ELF even contains a customization hook called &quot;program interpreter&quot; in every executable!).&lt;/p&gt;
&lt;p &gt;Likewise, modern compilers and runtime systems such as GNU C contain sophisticated features aimed squarely at dynamic languages: &lt;a href=&quot;http://www.embedded-bits.co.uk/tag/weak-symbols/&quot;&gt;weak symbols&lt;/a&gt; for runtime redefinability (used by libc&#039;s malloc and in the Linux kernel, for example), &lt;a href=&quot;http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Labels-as-Values.html&quot;&gt;computed gotos&lt;/a&gt;, &lt;a href=&quot;http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html&quot;&gt;nested functions&lt;/a&gt;, and increasingly, GC.  And there is &lt;a href=&quot;http://varnish.projects.linpro.no/wiki/VarnishFeatures&quot;&gt;evidence&lt;/a&gt; that dynamic compilation and linking of C snippets is accepted and used in modern systems software.&lt;/p&gt;
&lt;p &gt;I have collected some links to these topics, and would be interested to hear of languages and systems that you know that exploit them.&lt;/p&gt;
&lt;ul &gt;
&lt;li &gt;&lt;a href=&quot;http://www.iecc.com/linker/&quot;&gt;Linkers and Loaders&lt;/a&gt;. A very well-written book with broad coverage of the topics discussed, that is available for free.
&lt;li &gt;The Linux &lt;a href=&quot;http://tldp.org/HOWTO/Program-Library-HOWTO/&quot;&gt;Program Library HOWTO&lt;/a&gt; talks about dynamic loading under Linux.
&lt;li &gt;&lt;a href=&quot;http://www.skyfree.org/linux/references/ELF_Format.pdf&quot;&gt;Executable and Linkable Format (ELF)&lt;/a&gt; specification, 60 pages of highly compressed information in best Bell Labs style.
&lt;li &gt;&lt;a href=&quot;http://refspecs.freestandards.org/elf/&quot;&gt;ELF and ABI Standards&lt;/a&gt;. These specifications describe the actual layouts of things such as stack frames and ELF data structures for different CPUs.
&lt;li &gt;&lt;a href=&quot;http://www.phrack.com/issues.html?issue=56&amp;amp;id=7&quot;&gt;Shared library call redirection via ELF PLT infection&lt;/a&gt;. This article shows a technique that could be used to implement a REPL and other important dynamic language features solely through link-time operations.
&lt;li &gt;&lt;a href=&quot;http://l4u.jinr.ru/usoft/WWW/www_debian.org/Documentation/elf/elf.html&quot;&gt;ELF: From The Programmer&#039;s Perspective&lt;/a&gt;: &lt;em &gt;&quot;Combined with appropriate tools, programmers can use ELF to control the flow of execution at run time.&quot;&lt;/em&gt;
&lt;li &gt;&lt;a href=&quot;http://people.redhat.com/drepper/dsohowto.pdf&quot;&gt;How to Write Shared Libraries&lt;/a&gt;, an in-depth look by glibc&#039;s Ulrich Drepper (thanks, kkourt).
&lt;li &gt;&lt;a href=&quot;http://www.airs.com/blog/index.php?s=linker&quot;&gt;Series of articles on linkers&lt;/a&gt; by Ian Lance Taylor, the author of the &lt;code &gt;gold&lt;/code&gt; linker.
&lt;/ul&gt;
&lt;p &gt;(Updates: added 3 ELF links; added Drepper; added Taylor)&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/8">Implementation</category>
 <pubDate>Tue, 30 Jun 2009 11:52:42 -0400</pubDate>
</item>
<item>
 <title>Fully-parameterized, first-class modules with hygienic macros</title>
 <link>http://lambda-the-ultimate.org/node/3468</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://w210.ub.uni-tuebingen.de/frontdoor.php?source_opus=2423&amp;amp;la=de&quot;&gt;Fully-parameterized, first-class modules with hygienic macros&lt;/a&gt;, dissertation by Martin Gasbichler, 2006.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
It is possible to define a formal semantics for configuration, elaboration, linking, and evaluation of fully-parameterized first-class modules with hygienic macros, independent compilation, and code sharing. This dissertation defines such a semantics making use of explicit substitution to formalize hygienic expansion and linking. In the module system, interfaces define the static semantics of modules and include the definitions of exported macros. This enables full parameterization and independent compilation of modules even in the presence of macros. Thus modules are truly exchangeable components of the program. The basis for the module system is an operational semantics for hygienic macro expansion - computational macros as well as rewriting-based macros. The macro semantics provides deep insight into the nature of hygienic macro expansion through the use of explicit substitutions instead of conventional renaming techniques. The semantics also includes the formal description of Macro Scheme, the meta-language used for evaluating computational macros.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;A very readable, interesting, and useful work. &lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/15">Meta-Programming</category>
 <pubDate>Fri, 19 Jun 2009 14:20:47 -0400</pubDate>
</item>
<item>
 <title>Peter Van Roy: Programming Paradigms for Dummies</title>
 <link>http://lambda-the-ultimate.org/node/3465</link>
 <description>&lt;p &gt;Roy, Peter van (2009). &lt;a href=&quot;http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf&quot;&gt;Programming Paradigms for Dummies: What Every Programmer Should Know&lt;/a&gt;. In G. Assayag and A. Gerzso (eds.) &lt;em &gt;New Computational Paradigms for Computer Music&lt;/em&gt;, IRCAM/Delatour, France.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt; This chapter gives an introduction to all the main programming paradigms, their underlying concepts, and the relationships between them. We give a broad view to help programmers choose the right concepts they need to solve the problems at hand. We give a taxonomy of almost 30 useful programming paradigms and how they are related. Most of them differ only in one or a few concepts, but this can make a world of difference in programming. We explain briefly how programming paradigms influence language design, and we show two sweet spots: dual-paradigm languages and a definitive language. We introduce the main concepts of programming languages: records, closures, independence (concurrency), and named state. We explain the main principles of data abstraction and how it lets us organize large programs. Finally, we conclude by focusing on concurrency, which is widely considered the hardest concept to program with. We present four little-known but important paradigms that greatly simplify concurrent programming with respect to mainstream languages: declarative concurrency (both eager and lazy), functional reactive programming, discrete synchronous programming, and constraint programming. These paradigms have no race conditions and can be used in cases where no other paradigm works. We explain why for multi-core processors and we give several examples from computer music, which often uses these paradigms.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;I have not found this paper in the LTU archives, but I though it is likely of interest to this community. Of course, the author is well know here (e.g., his book Concepts, Techniques, and Models of Computer Programming). I like the bird&#039;s eye view of this paper.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/1">LtU Forum</category>
 <pubDate>Thu, 18 Jun 2009 12:55:46 -0400</pubDate>
</item>
<item>
 <title>Factor Mixins</title>
 <link>http://lambda-the-ultimate.org/node/3463</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://factor-language.blogspot.com/2007/08/mixins.html&quot;&gt;Mixins&lt;/a&gt;, a very interesting post from Slava Pestov&#039;s Factor blog.&lt;/p&gt;
&lt;blockquote &gt;
&lt;p &gt;Factor&#039;s object system allows the following operations without forcing unnecessary coupling:&lt;/p&gt;
&lt;p &gt;    * Defining new operations over existing types&lt;br &gt;
    * Defining existing operations over new types&lt;br &gt;
    * Importing existing mixin method suites into new types&lt;br &gt;
    * Importing new method suites into existing types&lt;br &gt;
    * Defining new operations in existing mixin method suites&lt;br &gt;
    * Defining new mixin method suites which implement existing operations&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;That&#039;s pretty much what I want from an object-functional language.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/12">Object-Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/17">Software Engineering</category>
 <pubDate>Thu, 18 Jun 2009 00:00:16 -0400</pubDate>
</item>
<item>
 <title>Mental animation: Inferring motion from static diagrams of mechanical systems. </title>
 <link>http://lambda-the-ultimate.org/node/3462</link>
 <description>&lt;small&gt;Hegarty, M. (1992).  &lt;a href=&quot;http://www.psych.ucsb.edu/~hegarty/papers/hegarty92.pdf&quot;&gt;Mental animation: Inferring motion from static diagrams of mechanical systems&lt;/a&gt;.  Journal of Experimental Psychology: Learning, Memory and Cognition, 18(5) 1084-1102&lt;/small&gt;&lt;p&gt;
&lt;blockquote&gt;
Reaction-time and eye-fixation data are analyzed to investigate how people infer the kinematics of simple mechanical systems (pulley systems) from diagrams showing their static configuration. It is proposed that this mental animation process involves decomposing the representation of a pulley system into smaller units corresponding to the machine components and animating these components in a sequence corresponding to the causal sequence of events in the machine&#039;s operation. Although it is possible for people to make inferences against the chain of causality in the machine, these inferences are more difficult, and people have a preference for inferences in the direction of causality. The mental animation process reflects both capacity limitations and limitations of mechanical knowledge.
&lt;/blockquote&gt;&lt;p&gt;
Following the theme of yesterday&#039;s post this is another non-PL research paper that explores cognitive factors that might be relevant to programming language design.&lt;p&gt;
The research in the paper nicely illustrates how different accounts of the cognitive processes involved in reasoning about the behavior of a mechanical system or model can be compared experimentally. The results suggest the types of inferences that are involved in mental animation of the type requested from the subjects, and how they are orchestrated.&lt;p&gt;
The first section of the paper provides the general framework, and explains the notion of mental animation. A discussion of the generality of the results can be found at the end of the paper.&lt;p&gt;
Those who find my last two posts too far removed from PL issues need not worry; I am not going to post more research of this type soon. Those who are intrigued by this research will be happy to know that a lot more is available &lt;a href=&quot;http://www.psych.ucsb.edu/~hegarty/publications.php#mr&quot;&gt;where this came from&lt;/a&gt;.</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Wed, 17 Jun 2009 20:59:01 -0400</pubDate>
</item>
<item>
 <title>Why a diagram is (sometimes) worth ten thousand words</title>
 <link>http://lambda-the-ultimate.org/node/3460</link>
 <description>&lt;small&gt;Jill Larkin and Herbert Simon, &lt;a href=&quot;http://social.cs.uiuc.edu/class/cs591kgk/LarkinSimon87.pdf&quot;&gt;Why a diagram is (sometimes) worth ten thousand words&lt;/a&gt;. Cognitive Science, 1987.&lt;/small&gt;&lt;p&gt;
&lt;blockquote&gt;
The  advantages  of  diagrams,  in  our  view,  are  computational.  That  is diagrams  can  be better representations  not  because  they  contain  more  information,  but  because  the  indexing  of  this  information  can  support  extremely  useful  and  efficient  computational  processes.  But  this  means  that  diagrams are  useful  only  to  those  who  know  the  appropriate  computational  processes for  taking advantage  of  them.  Furthermore,  a  problem  solver  often  also needs  the  knowledge  of  how  to construct  a  &quot;good&quot;  diagram  that  lets  him  take  advantage  of  the  virtues  we have  discussed.  In  short,  the  ideas  we have presented,  not  only  provide  an  explanation  of  why  diagrams  can  be  so  useful,  but  also  provide  a  framework  for  further  study  of  the  knowledge  required  for  effective  diagram  use. 
&lt;/blockquote&gt;&lt;p&gt;
While this paper is not about programming languages, it describes research that may be relevant to the discussion of visual programming languages versus textual languages as well as other language design decisions. Seeing as human factors were recently mentioned, and that it seems to be cognitive-week here on LtU, I thought this paper might be of interest.&lt;p&gt;
While I am sure this paper can be discussed from many angles, I&#039;ll only mention two. 1. While this paper is old, I still find it remarkable how old fashioned it seems. I am not sure exactly what causes it to feel this way; probably something in the writing style. 2. While I haven&#039;t searched the literature, I don&#039;t recall seeing research on programming languages that uses the framework suggested by this paper even though Simon&#039;s work was, of course, well known to computer scientists in general, and PL researchers in particular. </description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Wed, 17 Jun 2009 01:35:15 -0400</pubDate>
</item>
<item>
 <title>A-Z of Programming Languages: Erlang</title>
 <link>http://lambda-the-ultimate.org/node/3459</link>
 <description>&lt;p &gt;The latest entry has Joe Armstrong discussing &lt;a href=&#039;http://www.computerworld.com.au/article/307418&#039;&gt;Erlang&lt;/a&gt; in the ongoing series of interviews with PL designers (&lt;a href=&#039;http://lambda-the-ultimate.org/node/2873&#039;&gt;The A-Z of Programming Languages&lt;/a&gt;).  Two related things caught my eye.  The first is the obvious truism about language features:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Removing stuff turns out to be painfully difficult. It&#039;s really easy to add features to a language, but almost impossibly difficult to remove things. In the early days we would happily add things to the language and remove them if they were a bad idea. Now removing things is almost impossible.&lt;/blockquote&gt;
The other thing that I found intriguing was his mention of integrating version control into the language:&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;We have mechanisms that allow the application software to evolve, but not the language and libraries itself. We need mechanisms for revision control as part of the language itself. But I don&#039;t know how to do this. I&#039;ve been thinking about this for a long time.  Instead of having external revision control systems like Git or Subversion I&#039;d like to see revision control and re-factoring built into the language itself with fine-grain mechanism for introspection and version control.&lt;/blockquote&gt;
Not sure what he has in mind?&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/7">History</category>
 <pubDate>Tue, 16 Jun 2009 10:46:23 -0400</pubDate>
</item>
<item>
 <title>How Does Our Language Shape The Way We Think?</title>
 <link>http://lambda-the-ultimate.org/node/3457</link>
 <description>&lt;p &gt;Seems like its been a while since we last grated our linguistic experts.  From &lt;a href=&#039;http://edge.org/3rd_culture/boroditsky09/boroditsky09_index.html&#039;&gt;How Does Our Language Shape The Way We Think?&lt;/a&gt; by Lera Boroditsky, the age-old discussion gets reopened:&lt;br &gt;
&lt;blockquote &gt;Such a priori arguments about whether or not language shapes thought have gone in circles for centuries, with some arguing that it&#039;s impossible for language to shape thought and others arguing that it&#039;s impossible for language not to shape thought. Recently my group and others have figured out ways to empirically test some of the key questions in this ancient debate, with fascinating results.&lt;/blockquote&gt;
Being the Programming Languages weblog, issues surrounding languages in general are somewhat tangential.  Unlike the linguists, it is generally accepted that programming language syntax and semantics does have a significant effect on design and construction of programs.  But like liguistics, one would be hard pressed to isolate the language from the community (culture).  My take would be that a large measure of the benefit of looking at new PLs derives from being exposed to differing communities - not just in learning the details of a language.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Mon, 15 Jun 2009 12:59:15 -0400</pubDate>
</item>
<item>
 <title>Lectures on Jacques Herbrand as a Logician</title>
 <link>http://lambda-the-ultimate.org/node/3341</link>
 <description>&lt;p &gt;Wirth, Siekmann, Benzmueller &amp;amp; Autexier.  &lt;a href=&quot;http://arxiv.org/abs/0902.4682&quot;&gt;Lectures on Jacques Herbrand as a Logician&lt;/a&gt;.  SEKI Report SR-2009-01.&lt;/p&gt;
&lt;p &gt;Herbrand&#039;s work, more than that of any other, provides the intellectual foundations of logic programming.  This very readable article discusses Herbrands&#039; contributions to proof theory and the formulation of the idea of a recursive function, and most importantly to PL, his fundamental theorem that yields a semi-decision algorithm for first-order logic and his unification algorithm.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/19">Theory</category>
 <pubDate>Fri, 05 Jun 2009 09:42:07 -0400</pubDate>
</item>
<item>
 <title>Peter Landin </title>
 <link>http://lambda-the-ultimate.org/node/3340</link>
 <description>&lt;p &gt;I was just forwarded a message that Peter Landin passed away yesterday.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
From: Edmund Robinson&lt;br &gt;
Date: 4 June 2009 09:10:11 GMT+00:00&lt;br &gt;
Subject: Peter Landin&lt;/p&gt;
&lt;p &gt;I am very sorry to inform you that Peter Landin died yesterday of natural causes.&lt;/p&gt;
&lt;p &gt;For those members who are several generations away from Peter&#039;s early contributions, he was one of the major figures in the UK at the time that Computer Science was beginning to establish itself as a discipline. Some of his papers from 40 years ago are essential reading for any serious student of programming languages as still the simplest and clearest exposition of ideas that remain fundamental. The ideas in his papers were truly original and beautiful, but Peter never had a simplistic approach to scientific progress, and would scoff at the idea of individual personal contribution. Some of his own greatest ontribution to the field was as part of a golden nexus of work on programming languages in the UK in the late 60&#039;s and early 70&#039;s, containing Dana Scott and Christopher Strachey and others as well as Peter. The ideas they developed through their discussions truly lifted the study of programming languages to another level, and are now part of the bedrock of the subject.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Landin was one of the founders of our field, and did a lot of work of lasting value. We&#039;ve discussed his papers here many times before, even though some of them were written decades ago. He did work that cast a long shadow, or phrased better, did work that illuminated wide vistas. &lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Thu, 04 Jun 2009 13:14:41 -0400</pubDate>
</item>
<item>
 <title>Translation of Tree-processing Programs into Stream-processing Programs based on Ordered Linear Types</title>
 <link>http://lambda-the-ultimate.org/node/3335</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.kb.ecei.tohoku.ac.jp/~koba/papers/jfp-olt.pdf&quot;&gt;Translation of Tree-processing Programs into Stream-processing Programs based on Ordered Linear Types&lt;/a&gt;, Koichi Kodama, Kohei Suenaga, Naoki Kobayashi, JFP 2008. &lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
There are two ways to write a program for manipulating tree-structured data such as XML documents: One is to write a tree-processing program focusing on the logical structure of the data and the other is to write a stream-processing program focusing on the physical structure. While tree-processing programs are easier to write than stream-processing programs, tree-processing programs are less efficient in memory usage since they use trees as intermediate data. Our aim is to establish a method for automatically translating a tree-processing program to a stream-processing one in order to take the best of both worlds. &lt;/p&gt;
&lt;p &gt;We first define a programming language for processing binary trees and a type system based on ordered linear types, and show that every well-typed program can be translated to an equivalent stream-processing program. We then extend the language and the type system to deal with XML documents. We have implemented an XML stream processor generator based on our algorithm, and obtained promising experimental results.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Linear logic is what you get when you give up the structural rules of weakening and contraction -- it&#039;s logic when you cannot reuse or forget any hypothesis you make in the course of a proof. This means that every formula is used exactly once, which makes it useful (via Curry-Howard) for programming, as well: linear types give us a way of tracking resources and state in a type system. Intuitively, you can think of it as a kind of static analysis that ensures that an object&#039;s runtime reference count will always be one.&lt;/p&gt;
&lt;p &gt;However, linear logic retains the structural rule of &lt;a href=&quot;http://en.wikipedia.org/wiki/Exchange_rule&quot;&gt;exchange&lt;/a&gt;, which lets us use hypotheses in a different order than we introduced them. Ordered logic is what you get when you drop exchange, as well. (Amusingly, it was invented long before linear logic -- in the 1950s, Lambek introduced it with an eye towards applications in linguistics: he wanted to express the difference between one word occurring either before, or after, another.)&lt;/p&gt;
&lt;p &gt;This means that you can use ordered logic to express the order in your types the &lt;em &gt;order&lt;/em&gt; in which you use data, as well, which the authors here use to design a language whose typechecker statically rules out memory-inefficient programs.&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/21">Type Theory</category>
 <pubDate>Tue, 02 Jun 2009 10:12:56 -0400</pubDate>
</item>
<item>
 <title>Computing Needs Time</title>
 <link>http://lambda-the-ultimate.org/node/3332</link>
 <description>&lt;p &gt;&lt;i &gt;Edward A. Lee, &lt;a href=&quot;http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-30.pdf&quot;&gt;Computing Needs Time&lt;/a&gt;, Communications of the ACM, Volume 52, Issue 5 (May 2009).&lt;/i&gt;&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;The foundations of computing, rooted in Turing, Church, and von Neumann, are about the transformation of data, not about physical dynamics. This paper argues that we need to rethink the core abstractions if we really want to integrate computing with physical processes. In particular, I focus on a key aspect of physical processes that is almost entirely absent in computing, the passage of time. This is not just about “real-time systems,” which accept the foundations and retrofit them with temporal properties. Although that technology has much to contribute, I will argue that it cannot solve the problem alone because it is built on flawed foundations.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;The section of most direct relevance to LtU is probably section 5.2 on programming languages, which opens by saying:&lt;br &gt;
&lt;blockquote &gt;Programming languages provide an abstraction layer above the ISA. If the ISA is to expose selected temporal properties, and programmers wish to exploit this, then one approach would be to reflect these in the languages.&lt;/blockquote&gt;&lt;/p&gt;
&lt;p &gt;Also potentially of interest to the LtU readership is section 5.4 on formal methods, which closes by asserting that&lt;br &gt;
&lt;blockquote &gt;...type systems are formal methods that have had enormous impact. What is needed is &lt;b &gt;time systems&lt;/b&gt; with the power of type systems.&lt;/blockquote&gt;&lt;/p&gt;
&lt;p &gt;&lt;i &gt;Note:&lt;/i&gt; The &quot;Tagged Signal&quot; meta-model of computation mentioned in section 3 of the paper was previously discussed on LtU &lt;a href=&quot;http://lambda-the-ultimate.org/node/2982&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Sun, 31 May 2009 20:03:55 -0400</pubDate>
</item>
<item>
 <title>Going functional on exotic trades</title>
 <link>http://lambda-the-ultimate.org/node/3331</link>
 <description>&lt;small&gt;Simon Frankau, Diomidis Spinellis, Nick Nassuphis, Christoph Burgard. &lt;a href=&quot;http://www.lexifi.com/downloads/frankau.pdf&quot;&gt;Going functional on exotic trades&lt;/a&gt;. JFP 19(01):27-45.&lt;/small&gt;&lt;p&gt;
&lt;blockquote&gt;
The Functional Payout Framework (fpf) is a Haskell application that uses an embedded domain-specific functional language to represent and process exotic financial derivatives. Whereas scripting languages for pricing exotic derivatives are common in banking, fpf uses multiple interpretations to not only price such trades, but also to analyse the scripts to provide lifecycle support and more. This paper discusses fpf in relation to the wider trading workflow and our experiences in using a functional language in such a system as both an implementation language and a domain-specific language.&lt;/blockquote&gt;&lt;p&gt;
Section 3 is a nice discussion of why Haskell was chosen. Section 4 illustrates one of the major benefits of using DSLs, namely that different backends can be applied to programs written in the DSL, allowing various types of runtime behavior and analysis without the need to re-code each program for each purpose (thus n+m, rather than n*m programs).&lt;p&gt;
Another topic that may be worth discussing is the authors&#039; dislike of point free style.&lt;p&gt;
What we really need, of course, are DSLs for financial regulation (and possibly for specifying various definitions of honesty), but that&#039;s a separate issue...
</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/24">DSL</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/11">Functional</category>
 <pubDate>Sun, 31 May 2009 01:55:36 -0400</pubDate>
</item>
<item>
 <title>Questions Five Ways</title>
 <link>http://lambda-the-ultimate.org/node/3329</link>
 <description>&lt;blockquote &gt;&lt;p &gt;
I think one of the better ideas I&#039;ve had on this blog is my &lt;a href=&quot;http://on-ruby.blogspot.com/2009/05/questions-five-ways-overview.html&quot;&gt;Questions Five Ways&lt;/a&gt; series. For each post, I&#039;ll ask a guiding question of five leading hackers, some from the Ruby community and some from outside it.&lt;br &gt;
&lt;/blockquote&gt;
&lt;p &gt;
So far the questions were about concurrency, code reading, and static code analysis &amp;amp; testing. I understand Pat is interested in hearing suggestion for future topics.&lt;p &gt;
I find the discussion about concurrency interesting. Naturally we have been urging people to look at Erlang for quite awhile, and Haskell parallelism is also a frequent topic here. It is nice to see how these things are becoming more mainstream. It also means it is about time we moved on to new things...&lt;p &gt;
Code reading is, of course, &lt;a href=&quot;http://lambda-the-ultimate.org/node/1131&quot;&gt;near&lt;/a&gt; and dear to me.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/6">General</category>
 <pubDate>Thu, 28 May 2009 17:14:02 -0400</pubDate>
</item>
<item>
 <title>Forth Dimensions</title>
 <link>http://lambda-the-ultimate.org/node/3327</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.forth.org/fd/FDcover.html&quot;&gt;Forth Dimensions volumes 1-21&lt;/a&gt;, 1978-1999.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
The Forth Interest Group&#039;s bi-monthly, hard-copy magazine with an international circulation was founded in 1978. The owner of one of Silicon Valley&#039;s most successful computer bookstores called it, &quot;The best special-interest technical magazine ever&quot;. Forth Dimensions is no longer published.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;The site contains &lt;a href=&quot;http://www.forth.org/fd/contents.html&quot;&gt;scanned copies&lt;/a&gt; of every issue for download as PDF. Perhaps some Forth hackers can point us at the most interesting ones?&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/7">History</category>
 <pubDate>Sat, 23 May 2009 20:22:10 -0400</pubDate>
</item>
</channel>
</rss>
