RCL.grm
|
// FILE. . . . . /home/hak/ilt/src/ilog/rcl/RCL.grm // EDIT BY . . . Hassan Ait-Kaci // ON MACHINE. . Latitude407.Ilog.Biz // STARTED ON. . Wed Apr 26 10:17:23 2006 // Last modified on Wed May 03 20:39:19 2006 by hak
This is a Jacc grammar for the RIF Condition Language (RCL), whose BNF
grammar for a minimal "human-readable" syntax is described in the
proposal submitted to the W3C Working Group on the Rule Interchange
Format (RIF) by Harold Boley et al., on April 23, 2006. It is
meant to be able to express the abstract syntax form taken by
conditions of the rules that appear to be common to a reasonably
large variety of families of rule languages. The proposal in question is
available from the public RIF WG mail archive:
[RIF] Extensible Design. This Jacc grammar specification is a
literal transcription of the BNF rules given in the above reference.
This version of the RCL grammar is annotated for XML seralization. We give below the Jacc grammar rules for RCL. Note that the grammar they define is LALR(1). This HTML file is the root of a hyperlinked documentation allowing one to explore the grammar via navigation through its elements - rules, terminal and non-terminal symbols. The comments accompanying some rules come from the [RIF] Extensible Design mail. It also contains the pure Yacc rules. The documentation is generated by Jacc from the Jacc grammar specified in file RCL.grm. Along with this Jacc grammar file, there are other supporting source files. Essentially, the rule format is that of Yacc. As in Yacc, Jacc rules may be annotated with semantic actions, in the form of code involving the rule's RHS constituents (denoted by $1, $2, ..., $n - the so-called pseudo-variables where the index n in $n refers to the order of RHS constituents. Such actions appear between curly braces ('{' and '}') wherever a symbol may appear in a rule's RHS. Jacc also allows an additional form of annotation in the RHS of a rule to indicate the XML serialization pattern of the abstract syntactic tree (AST) node corresponding to a derivation with this rule. This XML serialization meta-annotation comes between square brackets ('[' and ']') and is of the form: [ XmlTag n_1 ... n_k ]where XmlTag is an identifier to use as XML tag for this
node in the XML serailization of the AST, and the n_k 's
are a sequence of numbers denoting positions of symbols in the RHS of
the rule (as for pseudo-varsiables but without '$'). The
number sequence indicates the order in which subnodes are to be
serialized. For example, the annotated rule:
QUANTIF : 'Exists' Var_plus '(' CONDIT ')' [ Exists 2 4 ] ;means that an AST node for this rule will be serialized thus: <Exists> (Xml serialization of Var_plus) (Xml serialization of CONDIT) </Exists>Rules without XML serialization annotation follow a default behavior: the serialization is the concatenation of those of its RHS's constituents, eliminating punctuation tokens (i.e., empty nodes and literal tokens - namely, tokens that do not carry a value). N.B.: The rules below (and supporting tokenizer) are of course a bare skeleton - yet it works! It parses correct RCL $CONDIT$ constructs and produces their XML serializations. Incorrectly formed constructs are rejected and produce a fatal syntx error - no error recovery is attempted. Of course, error recovery should be supported for more informative description of cause and location - Jacc can easily accommodate such a scheme with its built-in error recovery mechanism. If this primeval RCL should evolve into more elaborate languages akin to this RCL, this should and would be done, of course. For example, see the two test files Test.rcl and Test2.rcl. Running the command rcl on them produces the output shown in Test.run. |
%package ilog.rcl; %include "RCLCode.grm" // Help code for setting params and showing xml serialization %start RCL %token Data Ind Var Rel Fun %% RCL :
This rule is just a root for the non-terminal symbol denoting having recognized an RCL construct. For now, it recognizes a RIF condition as defined in [RIF] Extensible Design. Its semantic action amounts to print out the XML serialization of the parsed $CONDIT$ construct on the standard output. |
CONDIT { showXml(); } ; // Rules for CONDIT: CONDIT :
$CONJ$ is a $CONDIT$ expressing conjunctions of formulae. |
CONJ |
$DISJ$ is a $CONDIT$ expressing disjunctions of formulae. |
DISJ |
$QUANTIF$ stands for Quantified Formula, which for Horn-like conditions can only be '$Exists$' Formulas ($Var$+ variables should occur free in the scoped $CONDIT$, so '$Exists$' can quantify them). |
QUANTIF |
$LITFORM$ stands for Literal Formula and anticipates the introduction of $Atom$s or negated $Atom$s. |
LITFORM ; // Rules for CONJ: CONJ :
$CONJ$ represents conjunctions as prefixed '$And$' with zero or more
$CONDIT$ arguments.
Its XML serialization form is: <And> (XML serialization of $CONDIT_star$) </And> |
'And' '(' CONDIT_star ')' [ And 3 ] // XML serialization pattern ; // Rules for DISJ: DISJ :
$DISJ$ represents disjunctions as prefixed '$Or$' with zero or more
$CONDIT$ arguments.
Its XML serialization form is: <Or> (XML serialization of $CONDIT_star$) </Or> |
'Or' '(' CONDIT_star ')' [ Or 3 ] // XML serialization pattern ; // Rules for QUANTIF: QUANTIF :
This represents an existentially quantified formula using
prefixed '$Exists$' followed by zero or more $Var$s and a
$CONDIT$ between parentheses.
Its XML serialization form is: <Exists> (XML serialization of $Var_plus$) (XML serialization of $CONDIT$) </Exists> |
'Exists' Var_plus '(' CONDIT ')' [ Exists 2 4 ] // XML serialization pattern |
This represents a universally quantified formula using
prefixed '$Forall$' followed by zero or more $Var$s and a
$CONDIT$ between parentheses.
Its XML serialization form is: <Forall> (XML serialization of $Var_plus$) (XML serialization of $CONDIT$) </Forall> |
'Forall' Var_plus '(' CONDIT ')' [ Forall 2 4 ] // XML serialization pattern ; // Rules for LITFORM: LITFORM :
An $Atom$ a positive literal (i.e., a non negative $LITFORM$). |
Atom |
$Neg$ is classical negation as defined in first-order logic; special
uses of it can be shared by FO and all dialects that support a form of
classical negation (e.g., certain dialects of LP; perhaps some PR
dialects).
Its XML serialization form is: <Neg> (XML serialization of $Atom$) </Neg> |
'Neg' Atom [ Neg 2 ] // XML serialization pattern |
$Naf$ denotes negation as failure in one of its incarnations
(well-founded or stable-model). The actual flavor of Naf is determined
by inspecting the value of a semantic tag associated with the ruleset.
Naf is used in LP (and in queries and constraints over the intended
models of LP); it can possibly be relevant to PR and RR.
Its XML serialization form is: <Naf> (XML serialization of $Atom$) </Naf> |
'Naf' Atom [ Naf 2 ] // XML serialization pattern |
This allows one legal nesting of the two kinds of negations, for which
we propose to use the notation $Naf$/$Neg$, as in RuleML:
Its XML serialization form is: <NafNeg> (XML serialization of $Atom$) </NafNeg> |
'Naf' 'Neg' Atom [ NafNeg 3 ] // XML serialization pattern ; // Rules for Atom: Atom :
An $Atom$ represents an atomic formula using a prefixed '$Rel$'
predicate symbol with zero or more $TERM$ arguments.
Its XML serialization form is: <Rel> (XML serialization of $TERM_star$) </Rel> |
Rel '(' TERM_star ')' [ Atom 1 3 ] // XML serialization pattern |
Equality is a special $Atom$ represented with infix '$=$' between
two $TERM$s.
Its XML serialization form is: <Equal> (XML serialization of lhs $TERM$) (XML serialization of rhs $TERM$) </Equal> |
TERM '=' TERM [ Equal 1 3 ] // XML serialization pattern ; // Rules for TERM: TERM :
A $Data$ is a $TERM$ . |
Data |
An $Ind$ is a $TERM$ . |
Ind |
A $Var$ is a $TERM$ . |
Var |
An $Expr$ is a $TERM$ . |
Expr ; // Rules for Expr: Expr :
An $Expr$ represents functional expressions using a prefixed '$Fun$'
function symbol with zero or more $TERM$ arguments. Its XML
serialization form is:
<Expr> (XML serialization of lhs $Fun$) (XML serialization of rhs $TERM_star$) </Expr> |
Fun '(' TERM_star ')' [ Expr 1 3 ] // XML serialization pattern ; //////////////////////////////////////////////////////////////////////// // Rules for starred, plussed, and optional non-terminals ... CONDIT_star : /* empty */ | CONDIT_plus ; CONDIT_plus : CONDIT | CONDIT_plus CONDIT ; TERM_star : /* empty */ | TERM_plus ; TERM_plus : TERM | TERM_plus TERM ; Var_plus : Var | Var_plus Var ; //////////////////////////////////////////////////////////////////////// %%
This file was generated on Wed May 03 20:59:55 PDT 2006 from file RCL.grm
by the ilog.language.tools.Hilite Java tool written by Hassan Aït-Kaci