[JEXL] Blocks and an Expression

[Rahul Akolkar <ra...@gmail.com>]

Thanks for the recent changes Dion. The bit that is hazy (for me) is
the relationship between an Expression and a "block" in the current
impl. As demonstrated by the two failing test cases at the end of
BlockTest.java (and therefore, commented out) I think we may need to
flesh out the semantics of "value on Expression evaluation becomes
block value", especially when the Expression can contain multiple
blocks or a mix of blocks and statements.

I hope to look at the code soon as well ;-) but didn't want to lose
track of this initial thought while looking at the svn commits fly by.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JEXL] Blocks and an Expression

[Dion Gillard <di...@gmail.com>]

On 3/1/06, Rahul Akolkar <ra...@gmail.com> wrote:
<snip>
>
> > So, the question becomes, should we support multiple statements for an
> > expression (outside a block), or do we implement ASTJexlScript so that
> it
> > evaluates each of it's children in turn and returns the last value?
> >
> <snap/>
>
> Neither? ;-) Took a peek, the behavior is as advertised since a JEXL
> Expression is indeed a reference to a single expression, and those
> semantics need to persist. However, since we use the "script grammar"
> for the ExpressionFactory (whereas the grammar for scripts is really a
> superset of the expression grammar), we parse the (potential) script
> and pluck out the just first expression even if there are more. The
> fact that expressions beyond the first are silently ignored probably
> needs to be addressed. Short of teasing apart two grammars (and/or
> having a ScriptFactory), perhaps it will be sufficient to trivially
> log a warning when that happens.


A warning would be a good idea. I don't want to change the behaviour of
Expression to throw an exception if there is more than a single piece.

WDYT?
>
> As an independent question, why doesn't JEXL have Script as a first
> class entity like Expression (with a ScriptFactory to match)?


This sounds like a good thing to add to 1.1 - Loading and executing scripts.

-Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris

Re: [JEXL] Blocks and an Expression

[Rahul Akolkar <ra...@gmail.com>]

On 2/27/06, Dion Gillard <di...@gmail.com> wrote:
> Ok, I've found the cause of the problem.
>
> ExpressionFactory.createNewExpression on line 125 does this:
>
>        SimpleNode node = (SimpleNode) tree.jjtGetChild(0);
>
> So only the first statement of the parsed expression is actually evaluated.
>
> In the cases of the commented out tests, there are multiple statements which
> are children of the parse tree.
>
> The use of a block here really isn't significant, using a parse string like
> "x =1; y=2;" causes the same issue.
>
<snip/>

Agreed.

> So, the question becomes, should we support multiple statements for an
> expression (outside a block), or do we implement ASTJexlScript so that it
> evaluates each of it's children in turn and returns the last value?
>
<snap/>

Neither? ;-) Took a peek, the behavior is as advertised since a JEXL
Expression is indeed a reference to a single expression, and those
semantics need to persist. However, since we use the "script grammar"
for the ExpressionFactory (whereas the grammar for scripts is really a
superset of the expression grammar), we parse the (potential) script
and pluck out the just first expression even if there are more. The
fact that expressions beyond the first are silently ignored probably
needs to be addressed. Short of teasing apart two grammars (and/or
having a ScriptFactory), perhaps it will be sufficient to trivially
log a warning when that happens.

WDYT?

As an independent question, why doesn't JEXL have Script as a first
class entity like Expression (with a ScriptFactory to match)?

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JEXL] Blocks and an Expression

[Dion Gillard <di...@gmail.com>]

Ok, I've found the cause of the problem.

ExpressionFactory.createNewExpression on line 125 does this:

        SimpleNode node = (SimpleNode) tree.jjtGetChild(0);

So only the first statement of the parsed expression is actually evaluated.

In the cases of the commented out tests, there are multiple statements which
are children of the parse tree.

The use of a block here really isn't significant, using a parse string like
"x =1; y=2;" causes the same issue.

So, the question becomes, should we support multiple statements for an
expression (outside a block), or do we implement ASTJexlScript so that it
evaluates each of it's children in turn and returns the last value?

On 2/28/06, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 2/27/06, Dion Gillard <di...@gmail.com> wrote:
> > On 2/28/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > >
> > > Thanks for the recent changes Dion. The bit that is hazy (for me) is
> > > the relationship between an Expression and a "block" in the current
> > > impl. As demonstrated by the two failing test cases at the end of
> > > BlockTest.java (and therefore, commented out) I think we may need to
> > > flesh out the semantics of "value on Expression evaluation becomes
> > > block value", especially when the Expression can contain multiple
> > > blocks or a mix of blocks and statements.
> > >
> > > I hope to look at the code soon as well ;-) but didn't want to lose
> > > track of this initial thought while looking at the svn commits fly by.
> > >
> >
> > Hmm.. This seems to be the same as multiple expression evaluations, e.g.
> if
> > you evaluate:
> >
> > " x = 1; y = 2;"
> >
> > what do you expect? (me, I expect 2!).
> <snip/>
>
> Me too. But "if (true) { x = 1; } if (true) { y = 2; }" evaluates to ?
>
> A JEXL Expression (upper case 'E') may be more than, less than or
> equal to a block. For instance, a Perl code block can serve as an
> rvalue in an assignment expression, which is the kind of scenario
> where the value of the block mostly comes into play. In which case,
> there is exactly one block.
>
>
> > Blocks shouldn't change the
> > semantics.
> >
> > is that your understanding too?
> >
> > I can look at the failing/commented tests and check out what's happening
> if
> > you like.
> >
> <snap/>
>
> Please.
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris

Re: [JEXL] Blocks and an Expression

[Rahul Akolkar <ra...@gmail.com>]

On 2/27/06, Dion Gillard <di...@gmail.com> wrote:
> On 2/28/06, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > Thanks for the recent changes Dion. The bit that is hazy (for me) is
> > the relationship between an Expression and a "block" in the current
> > impl. As demonstrated by the two failing test cases at the end of
> > BlockTest.java (and therefore, commented out) I think we may need to
> > flesh out the semantics of "value on Expression evaluation becomes
> > block value", especially when the Expression can contain multiple
> > blocks or a mix of blocks and statements.
> >
> > I hope to look at the code soon as well ;-) but didn't want to lose
> > track of this initial thought while looking at the svn commits fly by.
> >
>
> Hmm.. This seems to be the same as multiple expression evaluations, e.g. if
> you evaluate:
>
> " x = 1; y = 2;"
>
> what do you expect? (me, I expect 2!).
<snip/>

Me too. But "if (true) { x = 1; } if (true) { y = 2; }" evaluates to ?

A JEXL Expression (upper case 'E') may be more than, less than or
equal to a block. For instance, a Perl code block can serve as an
rvalue in an assignment expression, which is the kind of scenario
where the value of the block mostly comes into play. In which case,
there is exactly one block.


> Blocks shouldn't change the
> semantics.
>
> is that your understanding too?
>
> I can look at the failing/commented tests and check out what's happening if
> you like.
>
<snap/>

Please.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JEXL] Blocks and an Expression

[Dion Gillard <di...@gmail.com>]

On 2/28/06, Rahul Akolkar <ra...@gmail.com> wrote:
>
> Thanks for the recent changes Dion. The bit that is hazy (for me) is
> the relationship between an Expression and a "block" in the current
> impl. As demonstrated by the two failing test cases at the end of
> BlockTest.java (and therefore, commented out) I think we may need to
> flesh out the semantics of "value on Expression evaluation becomes
> block value", especially when the Expression can contain multiple
> blocks or a mix of blocks and statements.
>
> I hope to look at the code soon as well ;-) but didn't want to lose
> track of this initial thought while looking at the svn commits fly by.
>

Hmm.. This seems to be the same as multiple expression evaluations, e.g. if
you evaluate:

" x = 1; y = 2;"

what do you expect? (me, I expect 2!). Blocks shouldn't change the
semantics.

is that your understanding too?

I can look at the failing/commented tests and check out what's happening if
you like.

--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris