Home » Modeling » TMF (Xtext) » syntatic predicates in Xtext 2.0
| | |
| Re: syntatic predicates in Xtext 2.0 [message #649672 is a reply to message #649641] |
Thu, 20 January 2011 08:15   |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
yes, =>RuleCall is possible and =>name=ID as well as =>('else' foo=Bar
'zonk'|'baz'), too.
We do currently not support predicates in terminal rules and what will
never be possible is to use unordered groups as predicates.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 20.01.11 03:30, schrieb Henrik Lindberg:
> Looks promising!
> Is it possible to have => RuleCall ?
>
> In my case the 'else' is something like:
> ElseRule : LOWER_E LOWER_L LOWER_S LOWER_E ;
> terminal LOWER_E : 'e' ;
> // etc
>
> Can the result be assigned? i.e. if I want the equivalence of op =
> 'else' as well as direct the parser.
>
> - henrik
>
> On 1/19/11 8:36 PM, Sebastian Zarnekow wrote:
>> Hi Henrik,
>>
>> taken from commit message
>> http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?i d=1aef0084ea6a83a98b9d91c02ec967e5c5a9fdf8
>>
>>
>>
>> Predicates can be defined in the Xtext grammar by means of the '=>'
>> keyword that prefixes the actual value that should be parsed, e.g.
>>
>> IfExpression:
>> 'if' '(' condition=Expression ')'
>> then=Expression
>> ( =>'else' else=Expression )?;
>>
>> will guide the parser to assign parse the 'else' eager and thereby
>> ensure that it will be part of the innermost if-expression.
>>
>> Does that help?
>>
>> Regards,
>> Sebastian
>
|
|
| | | |
| Re: syntatic predicates in Xtext 2.0 [message #650162 is a reply to message #649954] |
Sat, 22 January 2011 02:40 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The problem I am facing is that terminals allow specification of NOT,
but data rules do not, and since my "terminals" are context sensitive I
have to use data rules. If I could instead use a fragment and directly
use it in a datatype rule, it would save me from having long lists
specifying the various sets of valid characters. (Long lists which I
have a strong suspicion is the source of some of the performance
problems I am having.
So, fragments seems perfect to overcome this problem.
As an example, let's say that SL_COMMENT is context sensitive.
It is easily specified as a terminal.
terminal SL_COMMENT '#' .* ('\r'? '\n') ;
Doing the same with a data rule is possible, but requires listing every
possible source character in the language (which is what I did). Here is
the start of that:
SL_COMMENT
: HASH
( ANY_DIGIT
| ANY_LETTER
| PUNCTUATION
| SP | TAB | NBSP
)*
CR? // CR optional depending on file format
NL // NL optional because file may end with a SL comment
;
If I understood fragments correctly, I would be able to provide
something like
CommentedStatement : statement SL_COMMENT? ;
fragment SL_COMMENT '#' .* ('\r'? '\n') ;
Please let me know if there is some other way to achieve what I want, or
if I misunderstood the usefulness of fragments - if not I will post an
enhancement request. (I agree that they are not terribly useful if they
can only be used inside terminals or other fragments).
Another alternative is naturally to support NOT and ANY (.) in datatype
rules.
Support for semantic predicates, the above, and the ability to use
'\uxxxx' would make my life a lot easier.
Regards
- henrik
On 1/21/11 8:56 AM, Sebastian Zarnekow wrote:
> Henrik, Marc,
>
> they are currently not planned since we never faced the need for them.
> Please file a feature request with a sample terminal rule that cannot be
> expressed with the currently available abstractions.
>
> Thanks,
> Sebastian
|
|
|
| Re: syntatic predicates in Xtext 2.0 [message #650359 is a reply to message #650162] |
Mon, 24 January 2011 15:36 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Added: https://bugs.eclipse.org/bugs/show_bug.cgi?id=335203
as Sebastian suggested.
- henrik
On 1/22/11 3:40 AM, Henrik Lindberg wrote:
> The problem I am facing is that terminals allow specification of NOT,
> but data rules do not, and since my "terminals" are context sensitive I
> have to use data rules. If I could instead use a fragment and directly
> use it in a datatype rule, it would save me from having long lists
> specifying the various sets of valid characters. (Long lists which I
> have a strong suspicion is the source of some of the performance
> problems I am having.
>
> So, fragments seems perfect to overcome this problem.
>
> As an example, let's say that SL_COMMENT is context sensitive.
> It is easily specified as a terminal.
> terminal SL_COMMENT '#' .* ('\r'? '\n') ;
>
> Doing the same with a data rule is possible, but requires listing every
> possible source character in the language (which is what I did). Here is
> the start of that:
>
> SL_COMMENT
> : HASH
> ( ANY_DIGIT
> | ANY_LETTER
> | PUNCTUATION
> | SP | TAB | NBSP
> )*
> CR? // CR optional depending on file format
> NL // NL optional because file may end with a SL comment
> ;
>
> If I understood fragments correctly, I would be able to provide
> something like
> CommentedStatement : statement SL_COMMENT? ;
> fragment SL_COMMENT '#' .* ('\r'? '\n') ;
>
> Please let me know if there is some other way to achieve what I want, or
> if I misunderstood the usefulness of fragments - if not I will post an
> enhancement request. (I agree that they are not terribly useful if they
> can only be used inside terminals or other fragments).
>
> Another alternative is naturally to support NOT and ANY (.) in datatype
> rules.
>
> Support for semantic predicates, the above, and the ability to use
> '\uxxxx' would make my life a lot easier.
>
> Regards
> - henrik
>
> On 1/21/11 8:56 AM, Sebastian Zarnekow wrote:
>> Henrik, Marc,
>>
>> they are currently not planned since we never faced the need for them.
>> Please file a feature request with a sample terminal rule that cannot be
>> expressed with the currently available abstractions.
>>
>> Thanks,
>> Sebastian
>
|
|
|
| Re: syntatic predicates in Xtext 2.0 [message #650477 is a reply to message #650162] |
Tue, 25 January 2011 08:11 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Henrik,
as you already noticed, terminal fragments are already available. And
the good news is: unicode escapes are possible, too :-)
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 22.01.11 03:40, schrieb Henrik Lindberg:
> The problem I am facing is that terminals allow specification of NOT,
> but data rules do not, and since my "terminals" are context sensitive I
> have to use data rules. If I could instead use a fragment and directly
> use it in a datatype rule, it would save me from having long lists
> specifying the various sets of valid characters. (Long lists which I
> have a strong suspicion is the source of some of the performance
> problems I am having.
>
> So, fragments seems perfect to overcome this problem.
>
> As an example, let's say that SL_COMMENT is context sensitive.
> It is easily specified as a terminal.
> terminal SL_COMMENT '#' .* ('\r'? '\n') ;
>
> Doing the same with a data rule is possible, but requires listing every
> possible source character in the language (which is what I did). Here is
> the start of that:
>
> SL_COMMENT
> : HASH
> ( ANY_DIGIT
> | ANY_LETTER
> | PUNCTUATION
> | SP | TAB | NBSP
> )*
> CR? // CR optional depending on file format
> NL // NL optional because file may end with a SL comment
> ;
>
> If I understood fragments correctly, I would be able to provide
> something like
> CommentedStatement : statement SL_COMMENT? ;
> fragment SL_COMMENT '#' .* ('\r'? '\n') ;
>
> Please let me know if there is some other way to achieve what I want, or
> if I misunderstood the usefulness of fragments - if not I will post an
> enhancement request. (I agree that they are not terribly useful if they
> can only be used inside terminals or other fragments).
>
> Another alternative is naturally to support NOT and ANY (.) in datatype
> rules.
>
> Support for semantic predicates, the above, and the ability to use
> '\uxxxx' would make my life a lot easier.
>
> Regards
> - henrik
>
> On 1/21/11 8:56 AM, Sebastian Zarnekow wrote:
>> Henrik, Marc,
>>
>> they are currently not planned since we never faced the need for them.
>> Please file a feature request with a sample terminal rule that cannot be
>> expressed with the currently available abstractions.
>>
>> Thanks,
>> Sebastian
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 14:44:37 GMT 2024
Powered by FUDForum. Page generated in 0.02529 seconds |
] 
Search
Help
Register
Login
Home
