archives

JExamples

(via Keith)
We analyze the source code of production Java open source projects such as Ant, Tomcat and Batik and load that analysis into a java examples database designed for easy searching. You enter the name of a Java API Class.method you want to see example invocations of and click Search.

Nice idea. Looks like a useful resource.

Guido van Rossum: Building an Open Source Project and Community

A long (close to two hours) audio presentation about Python's history and philosophy.

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.

Calling imperative code from declarative?

I'm integrating imperative (OO) and declarative (Prolog-ish) languages. Accessing declarative constructs from imperative side is easy, as you can model them as an object model. The other direction is trickier. It is easy to represent OO data structures in predicate logic, but the concept of "calling" is difficult.

The standard approach, employed by numerous Prolog-embedded-in-Java tools, is to allow the user to give code to be run when given predicates are entered. It works, but is not very manageable. Are you aware of different solutions for this problem of turning declarative into imperative?

Threads Cannot be Implemented as a Library

Hans-J. Boehm. Threads Cannot Be Implemented As a Library. Proceedings of the ACM SIGPLAN 2005 Conference on Programming Language Design and Implementation, June 2005, pp. 261-268. Official version. Technical report version.

In many environments, multi-threaded code is written in a language that was originally designed without thread support (e.g. C), to which a library of threading primitives was subsequently added. There appears to be a general understanding that this is not the right approach. We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code. We first review why the approach almost works, and then examine some of the surprising behavior it may entail. We further illustrate that there are very simple cases in which a pure library-based approach seems incapable of expressing an efficient parallel algorithm. Our discussion takes place in the context of C with Pthreads, since it is commonly used, reasonably well specified, and does not attempt to ensure type-safety, which would entail even stronger constraints. The issues we raise are not specific to that context.

The paper includes several interesting examples, and reminds us yet again of the importance of formally well defined semantics.