[Oz] Factoring Mozart's Record Construct

[Peter Van Roy]

> One of the things that attracted me to Mozart was the generality of the
> features.  However, upon examining the language a bit more, I find myself a
> bit bewildered by the variety of constructs via which one can go about
> supplying a symbol to a composite entity and either setting or getting a
> value.  I undertand most of this is a stated goal of a multi-paradigm
> language and one can avoid bewilderment by picking a paradigm and sticking
> to it, but some of it is just confusing.

We are of course very interested in learning about what you find confusing.
One way to avoid confusion, as you suggest, is to stick to the paradigm you
know best and to bring in other paradigms only slowly, as you learn about
them.  For example, start with object orientation, and bring in other
concepts as you learn about them.  For example, first-class procedures
are a very nice way to ``package'' work and pass it as an argument.  This
is works well together with objects.  Another example is the use of symbolic
data (like lists and trees).  Lists are very compact and efficient; there is
no need to define lists as objects, e.g., as a LinkedList class with a set of 
methods.  On the contrary, symbolic lists are both more efficient and easier
to program with than LinkedList objects (both in Oz and Java).

> Perhaps the most obvious symptom of confusion is the way record labels
> frequently end up as redundant annoyances.  Has there been any consideration
> given to factoring the record construct into primitives that would include
> unlabeled feature lists to which labels may be afixed by operators?  Might
> record labels then be more seamlessly unified with the names of
> features/attributes?

You are right; records could indeed be factored in this way.  We have not done
so because the record label plays the role of a type identifier.  This makes it
easier to avoid confusing one record type for another: just give them different
labels.  You can give all records the same label, but this is not considered
good style.

Two data types related to records are dictionaries and record constraints.
Dictionaries have no labels and are the recommended data type to use when
the mapping changes.  Record constraints allow to give partial information
about records, for example, that two features are known but that the label
is not known yet.  Record constraints are intended for constraint
applications, for example, natural language processing.

Peter

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.