[Oz] Factoring Mozart's Record Construct

[Peter Van Roy]

> A significant number of the type labels could be removed without loss of
> clarity.  In too many cases the record label is just one more thing to
> remember and get wrong.  There is enough of substance to learn with Mozart
> already -- it doesn't need less substantive features getting in the way of
> acceptance.  If my experience is any indication this may be turning a lot
> more people away from Mozart in their initial impressions than you are
> likely to discover unless you do some careful outreach.  People don't have
> time to mess with every new technology that comes along -- and Mozart's
> record syntax is a big piece of its initial impression.  If it _appears_ it
> _might_ have thinking behind it, people will simply ditch it and not bother
> analyzing why they ditched it, let alone bothering to tell you the reasons
> why they ditched it.  This is particularly true of technologies that fresh
> from the lab.
> 

I'm not sure I really understand the issue you are raising.  Are you
serious that the mere existence of a 'record label' would be enough
to keep people from programming in Oz?  I would suggest that such
people are not motivated enough anyway to learn any new language.

If you want to use records without specifying a label, I suggest you
always use the label 'unit'.  This is just an atom.  It is already
good practice to use 'unit' wherever a token is needed whose value is
not important.  For example, for pure thread synchronization:

   thread ... X=unit ... end
   thread ... {Wait X} ... end

Records can have unit as label:

   declare
   R=unit(a:2 d:e)
   {Browse R}

In a more general setting, Oz has much support for symbolic data structures,
not just records, but also lists, trees, etc.  These data structures are
created by merely ``mentioning'' them, which is almost like drawing a picture.
For example, the QTk module for GUI design accepts symbolic data as input:

local
   Desc=td(lr(glue:nwe
	      label(glue:w text:"top left")
	      label(glue:e text:"top right"))
	   label(glue:s text:"middle bottom"))
in
   {{QTk.build Desc} show}
end

The data structure Desc describes a window with three labels, containing
the texts 'top left', 'top right', and 'middle bottom'.   In this example,
the record labels 'lr' (= left to right geometry), 'td' (= top down
geometry) and 'label' (= name of a widget) are definitely important.

In my own view, this way of specifying GUI design is better than a User
Interface Builder with a graphic interface: it gives a 'picture' of the
user interface at a high level of abstraction and it allows to
*compute* the descriptions.  It is just as easy to have a window with
1000 buttons as it is to describe a small number of buttons 'by hand'.
You can store and load the descriptions in files.  All this is provided
without introducing any new concepts to the language.

Data structures can also be taken apart by merely mentioning the form that
they have.  For example, Desc could be taken apart as follows:

local
   td(lr(A B glue:_) C)=Desc
in
   {Browse A#B#C}
end

This declares A, B, and C, and binds them to the
respective parts of Desc.  The browser shows:

  label(glue:w text:"top left")#label(glue:e text:"top right")#
  label(glue:s text:"middle bottom")

This illustrates the compactness and power of symbolic data structures
in Oz.  And what's more, these data structures have a very efficient
implementation: pretty much exactly what you would expect if you would
implement their functionality by hand.

Peter

-- 
Peter Van Roy
Département d'Ingénierie Informatique
(Department of Computing Science and Engineering)
Université catholique de Louvain
B-1348 Louvain-la-Neuve, Belgium

Email: pvr at info.ucl.ac.be
Tel: (+32) (10) 47.83.74
Web: http://www.info.ucl.ac.be/~pvr/
Mozart: http://www.mozart-oz.org


-
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/.