RE: sbnf (striped BNF)

>                    But I think you're suggesting having two real
> languages.

We could explore abstract-to/fro-concrete mappings in both
directions and then see which level we'll declare to be the
'primary' one (if any). But I am still assuming, following
common CS practice and earlier WG work, for spec purposes
we'll map from abstract to concrete ("top-down design").

> I understand mapping the instances automatically, but how do you map
the
> grammars automatically?  There's no way for the mapper to know you
want
> to use ":-" for implies, etc.   If you want to only maintain one
> grammar, I believe it has to be a fully-striped "concrete" one.

Besides a description of the abstract grammar, the mapper
needs -- passed to it as a 2nd parameter -- a (declarative)
description of the concrete operators (tokens and operand
orders) to be used -- for the abstract constructors -- in
each targeted concrete grammar.

The operator tokens can be specified by a table

constructor   operator token
 Equal         '='
 Implies       ':-'
 . . .         . . .

>From the abstract grammar's constructor patterns, the
operand orders, and the above operator token table,
these mapping rules can be derived:

abstract constructor pattern  concrete operator pattern
 Equal(side->a1 side->a2)      a1 '=' a2
 Implies(then->a1 if->a2)      a1 ':-' a2
 . . .

By modifying the operator token table, e.g. to

constructor   operator token
 Equal         '='
 Implies       '<-'
 . . .         . . .

and deriving the corresponding mapping rules

abstract constructor pattern  concrete operator pattern
 Equal(side->a1 side->a2)      a1 '=' a2
 Implies(then->a1 if->a2)      a1 '<-' a2
 . . .

a revised concrete grammar can be generated,
without touching the abstract grammar.

-- Harold

Received on Monday, 3 September 2007 20:17:06 UTC