First Mozart project: how to start?

[Joachim Durchholz]

Hi all,

I got the book, installed the docs, ran Emacs... but now I'd like to do 
something real, something beyond the prepackaged examples.
I'd like to write a "data entry normalizer". A rough outline of the 
project follows.
I don't need the algorithms (thanks, I've been programming pretty hairy 
stuff for a few years). What I do need is a list of things to download, 
and a list of docs/modules descriptions to read first. It's a small 
project, but it's real-world, I have little free time to spare, and all 
that, so I'd highly appreciate any advice that will save me hours of 
hunting down the relevant stuff.

I have emacs and a slightly outdated version of Mozart/Oz downloaded. 
I'm not familiar with emacs though, and the experience with it has 
been... well, mildly unpleasurable and unbelievably uncomformable. I'm 
pretty sure it's just a question of getting used to it, but 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.

Project description:
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? "curses" or something 
equivalent would be up to the task as well, but I haven't heard of any - 
and even then I'd need a confirmation that I could save some hours of 
work by using that library instead of GTK.)
Data entry would consist of lines like
   EW-1 2L,3B,4Pf
and the software will convert this to relational rows like (first line 
is field names, second line is converted form of input):
   Place A L S B Pf Remarks
   EW-1  0 2 0 3 4  ""
IOW there is some input parsing and validation involved - nothing too 
complicated, but something that lets me specify the syntax and an easy 
syntax-to-semantics mapping would be appreciated.
The syntax is simple, something like
   line ::= place element {"," element}
   element ::= number type {flag}
so something yacc-like might still be overkill.

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*.)

Users must be able to scroll through the data that they entered, and to 
add corrections. (IOW there are two representations that must be kept in 
sync: the input/edit representation for the user, and the relational 
representation for further internal processing. "Further internal 
processing" means: map the "Place" specifications into coordinates of a 
hexagonal grid and print the stuff... nothing that a standard module 
will help with, other than the ability to generate Postscript or 
something equivalent. Printing is on the "future plans" list though, 
I'll be happy if people can enter/edit and dump the whole thing to CSV 
format.)

Any responses are appreciated!

Regards,
Joachim
--
This is not an official statement from my employer.

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