If we are going to provide a separate parser and lexer, we need to use tools that generate the lexer and parser from definition files - we shouldn't write this code by hand, even if it is trivial.
While it's simple to write a lexer and parser, it's simpler to add new tokens
to a lexer definition file and actions to a parser definition file.
As a side benefit, as I mentioned previously, sister projects could take the
lexer and parser input files and change the parser actions to generate a
syntactically and semantically identical expression language - where folks
would have to write this themselves.
Even if it's trivial, writing this by hand is error prone compared to the
parser-generator alternative.
On re-using rules:
Each rule has two static getRule methods - one that takes a stack and one that
takes the expected number of params - we can definitely reuse the Rule classes.
Here's a bit of clarification on my use of postfix to create rules.
The postfix output is used to create the context stack that's passed in to
rules. ExpressionRule's PostFixExpressionCompiler.compileExpression returns a
single rule that is evaluated - this rule could be an AndRule, orRule, notRule,
or just an equalsRule, etc.
In your example the OrRule would short-circuit after the first rule evaluation.
Here's the contents of OrRule's evaluate method.
public boolean evaluate(LoggingEvent event) {
return (rule1.evaluate(event) || rule2.evaluate(event));
}
To summarize my usually long-winded email:
- I STRONGLY suggest we implement this expression language using a lexer and
parser generator.
- There's nothing preventing us from reusing the Rule classes - they provide
static getRule methods with the needed parameters
As a side note, we should not create yet another acronym as a package name -
could we move what you've just committed to o.a.l.expression?
Scott
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Thu 1/27/2005 6:58 AM
To: Log4J Developers List
Cc:
Subject: RE: [NEW] Log4j Boolean Expression Language (LBEL)
At 03:02 PM 1/27/2005, Scott Deboy wrote:
>I agree that writing the expression language using a lexer & parser is good.
>
>I've been working toward this goal and I was planning on using JFlex and
>byacc/J. Which lexer & parser does LBEL use?
Tools such as ANTLR know how to automatically transform "natural" grammars
to LL(k) or LR(k) form and then automatically generate a parser for the
transformed grammar. However, once you have a grammar in LL(1), writing a
top-down parser for it is almost a child's play. That's what I have done.
The hand crafted lexer is also quite simple (155 lines of Java).
>The conversion to postfix doesn't prevent short-circuiting during
>evaluation (supported by AndRule, OrRule).
In postfix form you can only avoid the evaluation of the next node. LBEL
skips whole branches several levels deep. Consider, the following expression.
true OR ((NOT false AND true) AND (true OR FALSE).
In postfix form it becomes:
true false NOT true AND true false OR AND OR
I don't see how the postfix form can avoid the evaluation of the whole
expression. (Note how the first OR becomes the last operator in the postfix
form.)
>The point of my previous email is two parts:
>- I'd like to see LBEL implement actions by relying on rules in o.a.l.rule.
Unfortunatley, they depend on the stack to retrieve operands don't they?
>- Where it makes sense (personal preference only), I'd like us to to keep
>as much of the existing operator and keywords as possible when issues like
>inconsistency and verbosity don't rule them out.
>
>A few language-questions:
>- Are parens supported?
Of course.
>- How are properties supported? prop.xxx, prop(x), or something else?
Not yet but that's easy to add.
>- How is legitimate white space supported? (single ticks, quotes?)
Within single ticks or quotes, both forms are allowed.
>- Spaces could show up in a property key...is that supported?
See previous answers.
>I'm looking forward to seeing the results.
Since you asked, I just committed the skeleton code for your convenience.
It is fairly straightforward code. More sophisticated version will follow
within the next few hours.
>Scott
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
