First Mozart project: how to start?

[Denys Duchier]

joachim at hact.de (Joachim Durchholz) writes:

> learning both emacs and Mozart at the same time seems like a
> sure way to end up in the insane asylum. I will continue on that road,
> unless somebody can tell me how to work with Mozart/Oz on Windows.

don't get your hopes up: you have to use emacs there too.  So keep
hiking to the asylum - we'll be waiting for you :-)

> The thing should be a data entry application. (I.e. focus is on
> usefulness for keyboard entry, with occasional mouse activity.)
> It must have a GUI, and it should be portable across (in descending
> priority) Windows, Linux, and MacOS. (I just hope that GTK is up to
> the task... or are there useful alternatives?

The current Mozart/Tk library will do this just fine, plus the mozart
standard library offers QTk which is a wonderful high-level interface
to the lower level Tk library: you provide a description of the GUI as
a term.  It's the most natural thing.

The new GTK bindings also offer such an interface (in fact inspired by
QTk because it was so nice), but it's very new and has so far rather
succint documentation.

Both alternatives work on at least Windows, Linux and MacOSX although
the GTK bindings still reveal portability issues since this is the
first time that they have been released i.e. confronted to fun issues
(NOT!) of practical portability in the real world :-)

> The syntax is simple, something like
>    line ::= place element {"," element}
>    element ::= number type {flag}
> so something yacc-like might still be overkill.

definitely overkill. even a trivial recursive descent parser would be
overkill. you just need a tokenizer and something to split a sequence
of tokens in subsequences separated by comma tokens.

I have to admit that I don't understand this line-oriented stuff if
you are supposed to have a GUI.

> Validation goes beyond syntax, there are some semantic checks as well
> (such as a constraint on the total number of elements per place). (A
> future plan is to allow specifying the elements for a place on
> multiple lines, i.e. allow multiple lines to add to a single
> place. This means I have constraints across multiple input lines -
> yucky but interesting, solving this in an elegant fashion will gain
> extra bonus points *g*.)

There is nothing yucky here.  The "lines", I imagine, are incremental
specifications/modifications of a model. The semantic constraints
apply to the model (is it admissible).

Keep in mind that when editing a model, you frequently have to pass
through non-admissible states (i.e. the model is temporarily
inconsistent).  In general, you cannot require that the model remain
consistent at all times (or there might be no path from here to
there).  One possibility is to update a list of issues.

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE
-
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/.
Please send bug reports to bugs at mozart-oz.org.