RE: sbnf (striped BNF)

"Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
> >                    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").

Yeah, it may not be imporant to declare one primary.  That's kind of
just a document-management question.  For users, the different level
grammars just need to agree with each other.

> > 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         '=3D'
>  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 '=3D' a2
>  Implies(then->a1 if->a2)      a1 ':-' a2
>  . . .
> 
> By modifying the operator token table, e.g. to
> 
> constructor   operator token
>  Equal         '=3D'
>  Implies       '<-'
>  . . .         . . .
> 
> and deriving the corresponding mapping rules
> 
> abstract constructor pattern  concrete operator pattern
>  Equal(side->a1 side->a2)      a1 '=3D' a2
>  Implies(then->a1 if->a2)      a1 '<-' a2
>  . . .
> 
> a revised concrete grammar can be generated,
> without touching the abstract grammar.

That's a nice vision, but how do you handle something complicated like
Uniterm?  Can you give me an example for a presentation syntax that has
commas between the arguments and one that does not....?  

When I do it, I end up with something like sbnf:
 
    Uniterm ::= op::Const "(" args::Uniterm* ")"
or
    Uniterm ::= op::Const "(" args::(Uniterm ("," Uniterm)*)? ")"

If the asn is to be completely redundant, we need to add a flag in there
that the arguments are ordered, perhaps like:

    Uniterm ::= op::Const "(" args::List(Uniterm*) ")"
    Uniterm ::= op::Const "(" args::List((Uniterm ("," Uniterm)*)?) ")"

I had thought you would like the idea of abandoning the abstract grammar
maintenance.  Since you don't, I'm not sure sbnf or something like it is
worthwhile.  I'm not sure there's much to be gained by automating the
mapping between a dialect's abstract grammar and its presentation
grammar.

      -- Sandro

Received on Wednesday, 5 September 2007 13:20:53 UTC