- From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
- Date: Mon, 3 Sep 2007 16:16:52 -0400
- To: "Sandro Hawke" <sandro@w3.org>
- Cc: <public-rif-wg@w3.org>
> 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