Lambda the Ultimate

(via Daily Python-URL)

The key idea behind MyHDL is the use of Python generators to model hardware concurrency. Generators are best described as resumable functions. In MyHDL, generators are used in a specific way so that they become similar to always blocks in Verilog or processes in VHDL.

A hardware module is modeled as a function that returns any number of generators. This approach makes it straightforward to support features such as arbitrary hierarchy, named port association, arrays of instances, and conditional instantiation.

MyHDL is an open-source package for using Python as a hardware description and verification language. A Verilog converter is also included.

EE Times provides some background on MyHDL in this article.

It rapidly became clear that a single language runtime is too limited for general applications ... as a minimum we needed both a linear-flow language and a recursive tree composition language ... while declarative languages are excellent for rapid assembly of XML operations, they are terrible for expressing business logic and logical flow-control ... Our other declarative language is XML Recursion Language (XRL). XRL is like XInclude with services, in which inclusion references fire service invocations into the URI address space in order to recursively compose an XML document. XRL is an elegant and powerful way of building XHTML applications ... The active URI, in combination with the local NetKernel environment, is a functional program - Introducing NetKernel.

Main site; Tour.

It's another XML pipeline (there's a Freshmeat project that lets Coccoon apps run in NetKernel), apparently from HP, which might interest people here.

LtU readers will find a lot to disagree with (especially in part 2), for instance when Guido discusses dynamic languages and typing. And yet, I think Guido tries to be reasonable, even though I disagree with some of his conclusions.

Be that as it may, this talk provides a useful summary of Python's history, and some idea about the workings of the Python community. Long time readers will remember that I think language communities play an important, yet under appreciated, role in language evolution and success.

Some solutions can be found here, if you need help getting started...

This recipe for using decorators to load data structures caught my eye (thanks to the Daily Python URL) as an interesting metaprogramming technique.

Decorators are function transformers that can be applied declaratively to normal Python methods and functions using the much-disputed decorator syntax (see this previous LtU thread). This recipe uses decorators that return the supplied function unmodified, but as a side-effect register it in a dictionary of handlers for various value conversion operations. The decorator code itself is called when the module is loaded, so the dictionary is populated "on demand" at run-time. This makes an interesting contrast with compile-time metaprogramming techniques such as C++ template metaprogramming and the use of code generators and preprocessors.

I do not believe that C# attributes could easily be used in a similar way, as unlike Python decorators these receive no information about the entities they are attached to when they are instantiated.

This recipe enables the use of the yield statement within a method by decorating that method with a wrapper for a generator object.

Say what you will about Python, it does provide us with clever tricks such as this one.

Interesting paper from PyCon 2003 (so yes, it's old news - but new on Lambda, as far as I can see): UCPy: Reverse-Engineering Python.

The project partly entails replacing the "CISC-style" Python VM with a much smaller "RISC-style" VM. The authors' comments on this decision are worth considering in the light of recent discussions about the design of the Parrot VM.

This is an absolutely blinding hack. See if you can guess how it's done before looking at the recipe...

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...

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.