Lambda the Ultimate

And imperative programming, and functional programming, and object-oriented programming, and logic programming, and constraint programming, and event-driven programming, and security, and modules, and...

Seriously, this is a mind-blowing book, the way "The Little LISPer" was when I first read it in high school, or SICP was when I first encountered it in college. But it covers many orders of magnitude more ground than its predecessors. This should be on literally everyone's shelves.

Any ideas how to do Distributed Functional Programming with “pure functional” data structures?

Chapter 4 of CTM gives a good start. The idea is to extend
a functional language with dataflow variables. This allows you to
organize your program as concurrent entities (we call them "stream
objects") that send each other messages, while still keeping the
pure functional semantics (e.g., no race conditions). It works with
both eager and lazy evaluation, and works just as well in a
centralized or distributed setting (see chapter 11).

But after reading the rest of your message, my impression is that
you want something else, which is not necessarily purely
functional: a way to keep stateful objects as transparent as
possible and as distributed as necessary. There are many ways
to do this. You can find a good overview of the issues in the
talk I gave at a Belgian Aspect-Oriented Programming
workshop. Some of the techniques given in that talk are
implemented in the Mozart system.

Yes I want something else, not just general-purpose frameworks and languages for parallel progrmming, like OZ, Erlang and Linda tuple space (that (Linda) I have some experienxce with and which certanly may help to get close to the goal of distributing state easily and efficiently).

Your phrase "a way to keep stateful objects as transparent as possible" is a good illustration of what I want, especialy I like the part "as possible"

This is a good understanding of the fact that in real life, real internet, in fact there is no such thing as "transperent stateful object". Stateful opbjects are not transperent at all! One may only want to find good enough mechanism to control this transperency in such a way that takes away some load of problems distributing state on the net from an application programmer, not usually an expert in this filed.

Nevertheless, this application programmer must be aware of the fact that application he is creating is in fact a distributed appliication with all implied limitations and consequences of this model.

And my questions here are:

1) What is an appropriate paradigm for distributed programming, better then stateful objects? I mean an abstraction that will allow application programmer to control distributed state (not neccessarily objects!) efficiently and define the scope of transperency as needed.

2)Can functional programming provide such an absrtaction and its efficient implementation?

3)Does it make sense to extend the abstarction of "pure functional data structures" (immutable, persitent data with history) to the network case?

So in fact I am looking more not for specific languages and frameworks here but to models and mechanisms that could be efficiently and convinently implemented as abstractions in functional languages.

Virtual Synchrony (VS)from Horus Project could be one of such mechanisms. I am not sure if VS was already explored in the context of some functional abstraction, though.

You also wrote:

The idea is to extend a functional language with dataflow variables. This allows you to organize your program as concurrent entities (we call them "stream objects") that send each other messages, while still keeping the pure functional semantics (e.g., no race conditions).

Sounds intresting. Do you have any papers on the "stream objects" available online? Or this is described in this book only?

Sounds intresting. Do you have any papers on the "stream objects" available online? Or this is described in this book only?

Well, it started in the book (Chapter 4 started as a "hole" -- a gap
in the computation models we knew, that we found while writing
the book) but you can look at the following article:

Declarative Laziness in a Concurrent Constraint
Language, 2nd International Workshop on Multiparadigm
Constraint Programming Languages (MultiCPL 2003),
September 2003.

This article explains the theory underlying the general model
(which does both eager and lazy execution) but it doesn't
really say much about the programming techniques. For those,
you might want to check out the programming course given
by Seif Haridi and Christian Schulte based on the book.

I still recommend you see how it's explained in the book, though.

Apart from being unusual to this C/Python programmer (me), I can't see why Oz's syntax is problematic. I'm in the inverse position: I like Oz over scheme because I'm not used to any of the two. And parentheses make me uneasy.

I understand why people are uncomfortable with Scheme's parentheses. I was to. But I got used to them rather quickly.

I am not using Oz daily, so maybe I am mistkaen, but I seem to remember being put off by the syntax of guards.

fun {Append Xs Ys}
  case Xs of X|Xr then
    X|{Append Xr Ys}
  else Ys end
end

Now, I know several programming languages, and this isn't the first time I see Oz code, and yet...

The curlies around the function signature is strange (even though I know Scheme...). Given the nature of the syntax, which resembles imperative languages, I'd expect only the parameters to be parenthesized.

The case statement introduces a binding, which is also a bit confusing. The order of reading isn't the natural order for me (X and Xr are the "subject" of this sentence, not Xs).

"end" is used both for "end fun" and "end case". I prefer to distinguish between different kinds of scope delimiters (unless you go for minimal syntax, like () in Scheme, {} in C, or whitespace in Python/Haskell - of which I am no great fan, but I can live with).

And oh, I really hate the keyword "fun". It's an English word, with quite a different meaning, and it distracts my reading.

All thse refelct my personal taste. So don't take this to be a flame against Oz. It's not.

*sigh*

Let me just give a few personal remarks in reaction to your detailed comments. The syntax of a language is always a delicate mix of principles, trade-offs, and practical issues. For me personally, syntax is not an issue unless it gets in the way of understanding the semantics. If it stays out of the way, like the Oz syntax does, then it is transparent. (It's like reading a book in translation: for me, reading a Dutch translation of The Hobbit is just a thin veneer over Tolkien's crisp English.) For Oz, we have put a lot of thought and practical experimentation in the syntax (as well as in the rest of the language). Upward compatibility with an existing syntax was not a design goal. On the contrary, it would mostly likely have given people the wrong intuition regarding semantics. Having a well-factored, simple, compositional syntax was much more important, especially considering how expressive the language is (see how short the syntax definition of appendix C is). For me, the Append example you give is very beautiful. Let me just this once reply to your specific remarks.

The curlies around the function signature is strange: Since parentheses were already taken for term syntax (tuples and records), curly brackets are a natural choice here.

The order of reading isn't the natural order for me: Well, the scope of the newly introduced X and Xr ranges over the 'then' clause, so the order is actually quite natural: match Xs against X|Xr. Doing it the other way would introduce no end of confusion (non-contiguous scopes of X and Xr).

"end" is used both for "end fun" and "end case": We experimented with other possibilities, and an 'end' at the end turned out to be simple, readable, and pleasing (for us, at least!).

I really hate the keyword "fun": See the subject line!

All these reflect my personal taste: This is your right. If everybody had the same taste, the world would be very boring.

Let me finish with a quote from Borges: "There is no good text that does not seem definitive if one turns to it a sufficient number of times." I would say that this applies to syntax as well!

I agree with this in general.

Since parentheses were already taken for term syntax (tuples and records), curly brackets are a natural choice here.

I wasn't complaining about the fact that you use curly barckets. I was referring to the fact that it's {Append Xs Ys Zs} and not Append{Xs Ys Zs}.

I didn't mean to make you *sigh*, sorry...

I could point out at Norvig's publishing of Python and Java source code in addition to Lisp for his AI book.