> Hi Peter,
>
> Sorry for the long delay in responding. Things have been busy & I wanted
> to give you a quality response. I have only started to learn Mozart at this
> point, so please take my assessment and reactions as tentative.
Now it's my turn to apologize for the long delay :-).
> First, some general remarks about E's goals, and how they probably differ
> from Mozart's.
>
...
>
> On the other hand, I know I can't see the future. I'm just taking the best
> shot I can. Perhaps the world can leap to Joule or Oz more directly than I
> expect, which would great. I wish you luck.
Personally, my motivation is similar to what Helmut Simonis of Cosytec has stated. They have developed a very powerful constraint programming system, for their own use. They abandoned long ago trying to teach it to "the hordes of C++ programmers". I share this view: what I am mainly interested in is a powerful tool for doing what I want to do. But this does not keep me from advertising Oz/Mozart as much as I can. (And other Oz/Mozart developers might have a different viewpoint than mine.)
On the other hand, a strong argument can be made that Oz would be a good first language for computer science students, e.g., avoiding the need to package Java, Haskell, and Prolog into one course. There are people going in this direction, and I am helping them all I can.
>
> At 12:35 AM 1/26/00 , Peter Van Roy wrote:
> >About the "constraint-based inference", here's an unabashed attempt to
> >persuade you :-).
...
>
> Well, I'm all in favor of "any kind of complex symbolic calculation".
Great!
>
> Pattern Matching
>
>
> Unification is too powerful. Instead, E has pattern-match-and-bind.
... (discussion on pattern matching in E)
Much of this is similar to Oz. The discussion of whether unification is too powerful or whether something weaker is enough is an interesting one, and the conclusion is not obvious. It's good to experiment both ways. We have found that full unification is not harder to implement in a distributed setting than 'distributed futures' (in the Multilisp sense), and its semantics is quite simple. The basic distributed operation is 'bind', which does a distributed variable elimination. So, we have decided to keep unification in the distributed implementation of Oz. See the May 1999 TOPLAS "Efficient Logic Variables for Distributed Computing" for more information (esp. Section 2.1.4).
>
> >One of the things that Oz supports efficiently is 'compound values'. Think
> >about it: integers are values, characters are values, but it's very rare to
> >have *values* that are bigger than than one memory word (lists, trees, ...).
> >Certainly not in C++ or Java. In those languages, values are "patched
> >together" with pointers. A compound value, on the other hand, does not
> >change. It can be sent across the network, and the language semantics
> >guarantees it will not change.
>
> Peter, I confess I have not been able to make sense of this paragraph.
> Certainly the semantics of C++ must talk about pointers, and the C++
> programmer must be painfully aware of them. But I don't see how they show
> up in Java's semantics any more than they show up in Oz's. If the issue is
> only immutability, it's easy in Java to write a class has only
> immutable instances: make all the instance variables "final".
I was not very clear. What I am trying to say is that Oz is
'paradigm-neutral',
while Java is not. That is, Oz is carefully designed not to make certain ways
of doing things much easier than other ways. Take lists, for example. It is
much more cumbersome to make immutable lists in Java than in Oz (how would
you create the list value [1 2 3]?). In Oz, values (in the mathematical sense)
are easy, as easy as in functional or logic programming. Yet, object-oriented
programming, in the Java style, is also easy in Oz.
>
> As far as being sent across the network, E has an explicit PassByCopy
> declaration (misnamed "selfless" in
> http://www.erights.org/elang/same-ref.html ). Like Oz values, an E
> PassByCopy object is immutable, is transparent (reveals its state to its
> clients), and has value-based equality rather than creation-based
> equality. Unlike Oz, their behavior is fully programmer definable in the
> normal object-oriented way, subject only to the immutability and
> transparency constraints.
What do you mean by the 'behavior of a value'? Do you mean the operations associated with it? In Oz, there is the notion of a 'chunk', which is a record without structure-based identity (if I understand you right, it has 'creation-based identity'), and which is used to build abstract data types. Chunks are not primitive values--they can be constructed with records and names (see below).
> Our PassByCopy data types are fully as extensible
> as our other data types. Have you considered allowing the non-privileged
> creation of new value types?
I don't understand exactly your question -- do you mean anything more than the creation of new value types, which is trivial in any dynamically-typed language? Oz distinguishes between representable values (e.g., lists, records, integers) and names (unforgeable unprintable constants), both of which can be created at runtime. The latter can be used as capabilities, in the sense of being unforgeable tickets that can be used to pass rights. This is very close to what E does, if I understand right. Names are the primitive concepts underlying fine-grained access control to object methods, for example.
>
> Again, I wish to make clear how much I admire what you folks have created.
> Though we perhaps have different goals, and will therefore pursue different
> means, I believe both our projects can benefit if we learn from each other.
> My responses will continue to be intermittent, but please let's keep the
> conversation going. Thanks.
>
> Cheers,
> --MarkM
>
Absolutely! I enjoyed very much your article "Capability-based Financial Instruments". I am very happy to see that others are thinking in the same direction as us and don't accept Java as 'the end of history'.
Peter