terminal INT returns ecore::EInt:('0'..'9') | (('1'..'9') ('0'..'9')+ ) ;

DECIMAL returns ecore::EString : '-'? INT ('.' INT)? ;

POSINTNUMBER returns ecore::EString : INT ;

NEGINTNUMBER returns ecore::EString : '-' INT ;

INTNUMBER:

POSINTNUMBER | NEGINTNUMBER ;

Again I understand that my DECIMAL rule can evaluate to INT in the case of say '12', but it actually works. I do get the right value. The only time these rules don't work is when the value starts with '0' for instance 0.1 creates an error. I resulted in making sure INT would allow a single digit (see INT rule above), but that didn't change anything.

Could someone tell me what I am missing? Again, everything works perfectly except the case 0.XXX '12' and '23.234234' work just fine, negatives too, POSINT and NETINT work well.

thanks,

JJ-]]>

If you're happy to model decimal as EString rather than EBigDecimal you

might just model aNumber and let the ValueConverters sort out the details.

Alternatively having INT return EString can give you more flexibility

over re-use again letting ValueConverters sort out the details.

[For OCL, where there are further ambiguities for e.g. "4..9" as a range

and "x.y" as a model navigation, the EssentialOCL grammar lies and

declares that a decimal is parsed as an INT, but actually a customized

TokenSource acts as a pre-lexer so that numeric '.' sequences appear to

Xtext as atomic tokens avoiding the need for clever disambiguation in

the subsequent rules.]

Regards

Ed Willink

On 17/09/2012 04:48, JJ Mising name wrote:

> I can't seem to find a way to model a decimal. These rules nearly work

> and I understand that there is an ambiguity with INT, but I am trying

> to create a decimal rule that would allow things like 0.1, 12,

> 23.234235 ...

>

>

> terminal INT returns ecore::EInt:('0'..'9') | (('1'..'9') ('0'..'9')+ ) ;

>

> DECIMAL returns ecore::EString : '-'? INT ('.' INT)? ;

>

> POSINTNUMBER returns ecore::EString : INT ;

>

> NEGINTNUMBER returns ecore::EString : '-' INT ;

>

> INTNUMBER:

> POSINTNUMBER | NEGINTNUMBER ;

>

> Again I understand that my DECIMAL rule can evaluate to INT in the

> case of say '12', but it actually works. I do get the right value. The

> only time these rules don't work is when the value starts with '0' for

> instance 0.1 creates an error. I resulted in making sure INT would

> allow a single digit (see INT rule above), but that didn't change

> anything.

> Could someone tell me what I am missing? Again, everything works

> perfectly except the case 0.XXX '12' and '23.234234' work just fine,

> negatives too, POSINT and NETINT work well.

> thanks,

>

> JJ-]]>

REAL hidden(): INT ? '.' (EXT_INT | INT);

terminal EXT_INT: INT ('e'|'E')('-'|'+') INT;

Note that REAL is not a terminal.

I also don't associate value converters with these as there are other

places where I need INT, REAL etc as strings. So I also have:

RealValue returns ecore::EDoubleObject: REAL ;

Hope that helps.

Regards

- henrik

On 2012-17-09 5:48, JJ Mising name wrote:

> I can't seem to find a way to model a decimal. These rules nearly work

> and I understand that there is an ambiguity with INT, but I am trying to

> create a decimal rule that would allow things like 0.1, 12, 23.234235 ...

>

>

> terminal INT returns ecore::EInt:('0'..'9') | (('1'..'9') ('0'..'9')+ ) ;

>

> DECIMAL returns ecore::EString : '-'? INT ('.' INT)? ;

>

> POSINTNUMBER returns ecore::EString : INT ;

>

> NEGINTNUMBER returns ecore::EString : '-' INT ;

>

> INTNUMBER:

> POSINTNUMBER | NEGINTNUMBER ;

>

> Again I understand that my DECIMAL rule can evaluate to INT in the case

> of say '12', but it actually works. I do get the right value. The only

> time these rules don't work is when the value starts with '0' for

> instance 0.1 creates an error. I resulted in making sure INT would allow

> a single digit (see INT rule above), but that didn't change anything.

> Could someone tell me what I am missing? Again, everything works

> perfectly except the case 0.XXX '12' and '23.234234' work just fine,

> negatives too, POSINT and NETINT work well.

> thanks,

>

> JJ-]]>

thank you very much for your reply.

I guess my DECIMAL rule was interfering with an array declaration '0..'

I did get it to go one step further with Henrik's suggestion and support .2 for 0.2, but I preferred replacing the a

Yes, I like/can make everything a String, this has worked best for me.

thank you again,

JJ-]]>