Python Optimization Surprises

This weekend, I took another crack at trimming microseconds off the common-case path for generic function execution, and succeeded in dropping the excution time from 13.2 microseconds to just over 9.8. (Which is about 9 microseconds overhead added relative to a hand-optimized Python version of the same trivial function.) Along the way, however, I realized a couple of surprising things about Python performance tuning.

An amusing story that tells you something about Python's implementation.

The discussion of closures is of particular interest...

An Introduction to Jython

Getting sick of Python posts by now? Sorry...

A large part of this presentation consists of a series of code examples showing how something is done in pure Java versus a Jython version. A nice illustration of the differences between the languages (did anyone say explicit static typing?) and about their different abstraction facilities and domain specific abstractions (e.g., builtin dictionaries and list comprehensions).

Analyzing these examples may be fun exercise idea for those of us teaching PL courses.

Implementation of FPL

Simon Peyton Jones book on the Implementation of Functional Programming Languages, circa 1987, is available online.

This book is about implementing functional programming languages using lazy graph reduction, and it divides itnto three parts.

The first part describes how to translate a high-level functional language into an intermediate language, called lambda calculus, including detailed coverage of pattern-matching and type checking. The second part begins with a simple implementation of the lambda calculus, based on graph reduction, and then develops a number of refinements and alternatives, such as super-combinators, full laziness and SK combinators. Finally, the third part describes the G-machine, a sophisticated implementation of graph reduction, which provides a dramatic increase in performance...

via the Haskell mailing lists. I've seen lots of references to this work, as it was one of the seminal works in the development of the Haskell programming language. But I can't find where it was directly discussed on LtU before.


A SPARK program has a precise meaning which is unaffected by the choice of Ada compiler and can never be erroneous.

From the examples in the chapter, I thought it looked surprisingly simple to use - comparable to adding contracts in DbC, for example. I guess the analysis requires a little more effort?

This has been mentioned only in passing by Ehud so I hope it's worth a post of its own. And I'm amused by the idea that Ada is a sloppy, ill-defined language... ;o)

Use Continuations to Develop Complex Web Applications

An introductory article from IBM developerWorks on Cocoon, continuation-based (sometimes called "modal") web applications, and such.

If you've ever developed a non-trivial Web application, you know that development complexity is increased by the fact that Web browsers allow users to follow arbitrary navigation paths through the application. No matter where the user navigates, the onus is on you, the developer, to keep track of the possible interactions and ensure that your application works correctly. While the traditional MVC approach does allow you to handle these cases, there are other options available to help resolve application complexity. Developer and frequent developerWorks contributor Abhijit Belapurkar walks you through a continuations-based alternative that could simplify your Web application development efforts.

via comp.lang.scheme

PyPy wins a funding contract with the EU

PyPy aims at producing a simple runtime-system for the Python language,

Our primary Scientific objective is to investigate novel techniques (based on Aspect-Oriented-Programming code generation and abstract interpretation) for the implementation of practical dynamic languages, breaking the compromise between flexibility, simplicity and performance trade-offs and expanding the range (small-to-large) of directly supportable runtime platforms.

CLR Generics and code sharing

I don't have the time at the moment to read it carefully, but this blog post looks promising.

Scheme on the CLR

Common Larceny (alpha release) is a CLI-targeted implementation of the Scheme programming language. The compiler generates MSIL and is interoperable with other .NET languages.
(spotter: Brad)

Skribe 1.2b released

(via comp.lang.scheme)

Erick Gallesio and Manuel Serrano have announced the release of version 1.2b of Skribe, a document processing language based on Scheme. From the home page:

Skribe is a text processor. Even [though] it is a general purpose tool, it best suits the writing of technical documents such as web pages or technical reports, API documentations, etc. At first glance, Skribe looks like a mark-up language à la HTML. So, there is no need to have developed computer programming skills to use Skribe.

A second look reveals that Skribe is actually a true programming language, provided with high level features (such as objects, higher order functions, regular and syntactic parsing, etc.). Skribe is based on the Scheme programming language.

From Skribe source files it is possible to produce various targets:

  • HTML pages that can be used to implement a web site (such as the Skribe Home Page).
  • XML files.
  • LaTeX files that can be used to produce high quality Postscript or PDF files.

What language enthusiast/researcher hasn't chafed at the language design of TeX? You should especially check out some of their cool examples.

Haskell Communities and Activities Report, Seventh Edition, November 2004

The November 2004 edition of the biannual Haskell Communities and Activities Report has been published. Lots of new stuff in the last six months, and some old stuff updated as well. The HC&AR has been steadily growing over the last three years, showing that FP is gaining users both professional and private.

Several of the HC&AR items are interesting enough to have their own LtU stories, which may appear shortly.

XML feed