Introduction and misc ideas

[Alexis Read]

On Thu, 6 Jun 2002, Brian T Rice wrote:
>
> AR>The other formalism that seems to be as powerful, is rewrite logic, which
> AR>has been developed further in CafeOBJ, Maude, ELAN and BOBJ. The
> AR>capabilities of Maude in particular have reached such a point where it is
> AR>almost usable to regular programmers.
>
> Except for the syntax. :) Which is why I'm suggesting a strategy of taking
> the underlying engine and stripping off the syntax and giving it a Lisp
> interface (the point being to take advantage of it in Arrow directly of
> course).

I'm not too clear on why the Maude syntax is so bad. I've 12 criteria
below for describing good syntax, all of which Maude supplies. (see the
maude manual section 2.5.3 for recursive terms)

(1) simple, elegant, homogeneous and
expressive syntax enhancing the code readability;
(2) functional, recursive definition of the language syntax, permitting
g(f(x)) and h(f(x),g(y)) constructs;
(3) clear evaluation rules with variable evaluation as the default
behaviour and non-evaluation as the exception;
(4) positional, optional and keyword parameters;
(5) concise default value mechanism minimising code clobbering;
(6) lexical scoping for clear semantics;
(7) collection orientation (Sipelstein and Blelloch 1990), permitting
operation on groups/sets as entities;
(8) macro definition capability allowing the construction of
``mini-languages'';
(9) interpreter for interactive code execution and compiler for efficiency;
(10) programmable parser (``reader'') allowing e.g., to locally modify
the language syntax;
(11) dynamic variable and function type assignment permitting omission of
unnecessary type declarations;
(12) block comments facilitating the task of commenting out several lines
of code.

All comments appreciated in the aid of enlightenment!

>
> AR>see the link I gave last time for Maude. The semantics are somwhat similar
> AR>to VHDL and ADA so if you're familiar with them, its easy to learn.
>
> Thanks for pointing that out. It hadn't occurred to me to emphasize the
> approach to Maude that takes its modules as ADTs to leverage an existing
> comfort that programmers already have with the subject. Maude just has
> some very nice semantics for building and combining ADTs. Whether it's
> algebraic rewrite or not could be considered by the programmer to just be
> a strategy to get the better overall results. Perhaps there's even a good
> basis for a Tunes explanation strategy.

The other point to mention is that syntax guides the programmer in the way
they think, which admittedly is a double edged sword. This can be
alleviated by giving example code, and so perhaps other issues become more
pressing, such as marketing familiarity (its similar to xxxx so you'll
pick it up (again double edged)), and the size of the command set and
syntax (KISS). The proviso is that the syntax is not restrictive.

In the case of LISP, and Maude, I don't see which has the more
advantageous syntax.

On a slightly different note, here's an attempt to create a visual
database language from a formally specified graph rewrite system. A step
up from SQL methinks!
http://www.liacs.nl/PhDThesis/andries-96.html

Alexis.