Preparing Mozart 1.4.0

[Bob Calco]

> 
> Dear Bob,
> 
> In short, the major change is the distribution layer.  It has been
> reimplemented completely on top of the DSS (Distribution SubSystem)
> library.  The DSS abstracts and generalizes the former distribution
> layer, and is no longer Mozart-specific.  It is mainly the work of Erik
> Klintskog (SICS, Sweden).
> 
> The new distribution support allows to choose between several protocols
> for each distributed entity.  As an example, for a given cell, one can
> choose between a stationary state protocol, two migratory state
> protocols, a protocol where the state is replicated on all proxy sites,
> and even no distribution at all, i.e., making the cell "sited".  A
> lease-based distributed garbage collection mechanism is also available.

Wow, that's quite exciting! 

> 
> The Fault module has also been redesigned and rewritten completely.
> Distribution-related exceptions and fault handlers have been discarded,
> because of their complexity and lack of modularity.  Fault watchers
> have
> been reduced to a simpler primitive: a stream of fault state for each
> entity.  The programmer can also provoke entity failure, which can be
> helpful for combining fault-tolerant abstractions.

This is interesting. How does it compare to Erlang's OTP mechanisms for
fault-tolerance? Seems at once lower level and more expressive.

> 
> We also have a certain number of small bug fixes.  We are preparing the
> document that lists all this stuff...

In my knight-errant's journey across the computing landscape I keep "coming
back" to Mozart, each time more experienced and more appreciative of what
it's all about. I'm a little slow on the uptake I guess... :-)  

Lately I've been in Erlang land, the streamlined concepts behind which have
given me a new appreciation for many of Oz's features and intended benefits,
most obviously those related to message-passing concurrency, but also
abstractions around fault-tolerance, high-availability (love the supervision
model capabilities baked into OTP), and the simpler pleasures--like the joy
of pattern matching and the miracle of lightweight threads. I never really
grokked those features at an experiential level before, and Erlang made it
easier for me to transition from Java/.NET with respect to those simple but
wonderful concepts. :)

I am actually working in a start up now in the variable content publishing
space, mostly with Erlang for the back-end distributed system I am building,
but some of the challenges I face brought Oz's CPI to mind recently. In
Erlang there is a library called Eresye that provides some of the AI-like
and ontological reasoning capabilities that I'm looking for, but I know of
nothing with the expressive power of Mozart for constraint-based
programming, and I will need that in some of the subsystems I'm building.

I wonder what it would be like to bridge Erlang and Mozart, or in any case
to get them to work together cooperatively. They both offer such compelling
benefits. The big one for Erlang relative to Oz anyway in terms of what I'm
working on is the bit syntax for pattern matching against binary streams. 

Erlang may not be the Swiss army knife of computing paradigms that Oz is,
but man, that bit syntax comes in handy when dealing with network protocols!
Also, I enjoy Mnesia, and working with database queries as "simple" list
comprehensions (which remove that whole "impedance mismatch" problem of
dealing with SQL back-ends, and the overhead of a bolted-on monad concepts
like LINQ in .NET) is quite fun. The "share nothing" philosophy and
insistence on referential integrity tells me that Erlangers would likely not
find Oz's support for shared state and data flow variables appealing, and
there is something to be said for Erlang's simplicity in this regard. But Oz
offers some really powerful alternative ways to think about solving
problems.

All of this by way of saying that this is the third or fourth time I have
circled back to Mozart-Oz. I find myself desirous to use it in some way now
more than ever, and the changes you've identified make this idea even more
appealing because of my familiarity and experience lately with Erlang. I
don't think I'll be chucking my investment in the Erlang code I've written
but I will be trying to leverage Oz for parts of what I'm working on.

Thank you guys for "still being here"! :)

- Bob
 
> Cheers,
> raph