You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Matías Giovannini <ma...@k-bell.com> on 2003/07/01 19:38:03 UTC
Re: Velocity Numerics : Floating Point Literals
On Thursday, June 26, 2003, at 08:00 PM, John J. Allison wrote:
> One problem is that the Java,C,C++,etc grammars all have full
> unary expressions represented. VTL only has logical not, with
> the unary minus for a negative number included in NUMBER_LITERAL.
Right, but these languages do constant expression evaluation at run
time, which VTL doesn't do (or does it?). Languages are more or less
evenly divided between signed literals vs. unsigned literals with unary
minus (and plus).
>
> Keeping close to current VTL grammar, here's the hard part:
>
> |
> <FLOATING_POINT_LITERAL:
> ("-")? (<DIGIT>)+ "." (<DIGIT>)* (<EXPONENT>)?
> | ("-")? "." (<DIGIT>)+ (<EXPONENT>)?
> | ("-")? (<DIGIT>)+ <EXPONENT>
>>
> |
> <#EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+ >
Can third case be folded into the first one, like this:
("-")? (<DIGIT>)+ ("." (<DIGIT>)*)? (<EXPONENT>)?
Also, maybe the grammar should permit a leading '+' in numeric literals
(many languages do, for regularity's sake).
> As for div operator, I say use "div". \ is the escape,
> and the other unused characters are not intuitive,
> i.e. not used by (m)any other languages.
The problem with "div" is that modulus is not called "mod" but "%".
Another problem was extreme reluctance to add new constructs to the
grammar, for reasons of backwards-compatibility. I'd say that a
word-like operator is more suspicious than a symbolic one, but it's
just a guess. What about "//"?
Matías.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Numerics : Floating Point Literals
Posted by Will Glass-Husain <wg...@forio.com>.
Matias,
Thanks for your input. I'll revise the syntax to include an optional
initial "+". I like the syntax "//" for div, personally.
The problem with Matias floating point syntax suggestion is that it doesn't
distinguish between a float and an integer. The reason we need to separate
these is that the range expression [1..3] needs to use an integer or
reference, not a floating point. This could have been handled by the Java
code but I thought it simpler to distinguish at the parser level.
I've gone ahead and done a first pass at implementing a decimal literal.
Here's the excerpt from Parser.jjt. (see my previous email for the full
patch for the literal, which builds on Peter R.'s patch for the
arithmetic/logic). Note that Peter is integrating all of this to make one
complete floating point number patch.
WILL
/**
* Note -- we also define an integer as ending with a double period,
* in order to avoid 1..3 being defined as floating point (1.) then a
period, then a integer
*/
| <INTEGER_LITERAL: ("-")? (<DIGIT>)+ ("..")? >
{
/*
* Remove the double period if it is there
*/
if (matchedToken.image.endsWith("..")) {
input_stream.backup(2);
matchedToken.image =
matchedToken.image.substring(0,matchedToken.image.length()-2);
}
/*
* check to see if we are in set
* ex. #set $foo = $foo + 3
* because we want to handle the \n after
*/
if ( lparen == 0 && !inSet && curLexState != REFMOD2)
{
stateStackPop();
}
}
| <FLOATING_POINT_LITERAL:
("-")? (<DIGIT>)+ "." (<DIGIT>)* (<EXPONENT>)?
| ("-")? "." (<DIGIT>)+ (<EXPONENT>)?
| ("-")? (<DIGIT>)+ <EXPONENT>
>
{
/*
* check to see if we are in set
* ex. #set $foo = $foo + 3
* because we want to handle the \n after
*/
if ( lparen == 0 && !inSet && curLexState != REFMOD2)
{
stateStackPop();
}
}
|
<#EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+ >
}
----- Original Message -----
From: "Matías Giovannini" <ma...@k-bell.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Tuesday, July 01, 2003 10:38 AM
Subject: Re: Velocity Numerics : Floating Point Literals
On Thursday, June 26, 2003, at 08:00 PM, John J. Allison wrote:
> One problem is that the Java,C,C++,etc grammars all have full
> unary expressions represented. VTL only has logical not, with
> the unary minus for a negative number included in NUMBER_LITERAL.
Right, but these languages do constant expression evaluation at run
time, which VTL doesn't do (or does it?). Languages are more or less
evenly divided between signed literals vs. unsigned literals with unary
minus (and plus).
>
> Keeping close to current VTL grammar, here's the hard part:
>
> |
> <FLOATING_POINT_LITERAL:
> ("-")? (<DIGIT>)+ "." (<DIGIT>)* (<EXPONENT>)?
> | ("-")? "." (<DIGIT>)+ (<EXPONENT>)?
> | ("-")? (<DIGIT>)+ <EXPONENT>
>>
> |
> <#EXPONENT: ["e","E"] (["+","-"])? (["0"-"9"])+ >
Can third case be folded into the first one, like this:
("-")? (<DIGIT>)+ ("." (<DIGIT>)*)? (<EXPONENT>)?
Also, maybe the grammar should permit a leading '+' in numeric literals
(many languages do, for regularity's sake).
> As for div operator, I say use "div". \ is the escape,
> and the other unused characters are not intuitive,
> i.e. not used by (m)any other languages.
The problem with "div" is that modulus is not called "mod" but "%".
Another problem was extreme reluctance to add new constructs to the
grammar, for reasons of backwards-compatibility. I'd say that a
word-like operator is more suspicious than a symbolic one, but it's
just a guess. What about "//"?
Matías.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org