Lambda the Ultimate

Given definitions of genetic algorithm and genetic programming, some PLT-inspired observations:

1. As interpreters are a special case of programs, then genetic programming is a special case of genetic algorithms. If this is correct, then some statements from referred articles at least need rewording (e.g., computational complexity).
2. It is (probably) interesting to investigate what are requirements for PLs being used as object language in genetic programming (e.g., set of (more or less) valid programs closed under mutations).
3. Related to the previous one - typing issues.
4. DSL perspective
5. Reflection, staged computation, etc. (bring in the slider).

Am I barking up the fallen tree? Any comments are appreciated.

Recently I released XSieve, an XML transformation language based on combination of XSLT and Scheme. XSieve makes XSLT to be a general-purpose language. Personally for me, XSieve is an alternative to XSLT 2.0.

Announce: http://sourceforge.net/forum/forum.php?forum_id=494165
What and why: http://xsieve.sourceforge.net/index.html#preface
Background: http://xsieve.sourceforge.net/background.html
Home page: http://xsieve.sourceforge.net/index.html
Project page: http://sourceforge.net/projects/xsieve/
XSieve in blog: http://uucode.com/blog/category/xsieve/

Your feedback is welcome!

According to amazon.com, Ravi, Sethi, and Ullman are (finally!!!) issuing a revision to the series of "Dragon Books"; this one is entitled Twenty-First Century Compilers. If amazon is to be believed, it should be published by the end of the year. Monica Lam (of Stanford) has been added to the author team as well.

Has anybody seen an advanced copy of the book? I know that Alfred Aho has been using it in his classes at Columbia, but I've seen little information on it otherwise (beyond the summaries at amazon and on Ullman's home page). Any comments on the new material?

And the important question (this may be a closely-guarded secret):

What color is the dragon on the cover?

Inquiring minds, as they say, wanna know.

As mentioned in a post last week, my experience with functional programming is pretty much all Scheme. I've gone through the SICP lectures and I get it... I am wary of !, and I understand why avoiding assignement is a good idea. After starting The Haskell School of Expression, I am curious as to people's visceral reaction to Haskell being a purely functional language. Do you find Haskell's approach creatively cumbersome at times? The feel I get from Haskell is that everything you program requires something "clever" in order to express it in a functional manner. Is that just my perception, is it a popular misnomer, or is it (even somewhat) true? I tend to sympathize with the kind of elitism that favors ideas that are "pure"... but can purity be an achiles heel? Why should I choose a language that denies me the understandibly dangerous power that accompanies assignment? What's "in it for me"? Is Haskell's type inference dependent upon assumptions about purity? Enlighten me, oh LtU gurus.

Spam messages will be deleted. I just deleted a message (an MFC library ad), and blocked the offensive user.

Using nomads to facilitate 'destructive' updates in a functional setting feels cumbersome and hack-ish for a (semi)-functional programmer like me.
An alternative would be to use persistent data structures that exploit the non-destructive property of purely functional ones, without incurring great costs.

Chris Okasaki has been one of the few researchers that seem to have been ignoring nomads all together. Instead, he has created very interesting alternatives called 'confluently persistent data structures' for almost all the traditional ones, such as lists, arrays and maps.

Armed with these algorithms, one could build a full (relational) database engine that doesn't destroy any data, but only adds it while still being able to jump to previous versions instantly - O(1) – giving enormous scalibility, distribution and accountability advantages over traditional solutions.

I've found one implementation of such a database: Herodotus. It isn't confluently persistent however, because it only has read access to previous versions, thus making it only 'partial persistent'.
Still, I think Herodotus may be the first, but also the next step in replacing the imperative world of database technology today.

Just as there's been work by Connor Mcbride on Epigram, there has been work by Hongwei Xi on ATS (previously mentioned on LTU). In one of his most recent papers, to appear at ICFP 05, a type system for a language which includes proof development facilities in the type system is presented . This work has an advantage of his previous work with DML in that type system is more expressive.

Etech draws a very connected crowd. It would be great if someone manages to get invited and talk about important issues (such as DSLs, abstraction, porgramming models). The CFP is here.

This year's topics provide some angles we (i.e., the programming languages communuty) can use. Discussion about this is welcome.

You can also suggest speakers you think are worth their attnetion (Peter van Roy, anyone?)

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?

"... go back to the starting point of procedural programming languages and extend them into a different direction in order to create advanced procedural languages which are significantly simpler than aspect-oriented languages while offering comparable expressiveness and flexibility."

APPLE: Advanced Procedural Programming Language Elements pdf