Home » Archived » IMP » Importing Syntax parser to IMP
Importing Syntax parser to IMP [message #21989] |
Mon, 30 June 2008 08:45 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Hello,
In the VASY team at INRIA, we have numerous compilers in our toolbox for
which we've used the Syntax (http://alpage.inria.fr/syntax.fr.html)
parser generator.
To build an Eclipse interface for our toolbox, we would need to somehow
port the grammars we wrote for Syntax to IMP.
I already see several problems in doing that. Syntax is C-based and we
can embed C code in grammar rules to tune them. Also, Syntax provides
predicates and actions that we typically use to recognize nested
structures or handle priorities. There are other things like the
terminals and the grammar rules being defined in different files with
different formats. The grammar in Syntax is described with a BNF
language while the terminals are described with regexp and operators on
characters set.
Facing these problems, we thought it might be easier to connect Syntax
to IMP (solution #2 in IMP manual). That would require a bit of hacking
but we think it might be easier than trying to translate the grammars
from the Syntax format to the LPG format.
The problem is that Syntax is written in C. I think we can implement the
interfaces to interact with IMP but the problem is the AST. If we have
to construct manually an AST for each grammar we're trying to port, then
it's easier to manually port the grammar. So I was thinking of
building an AST that follows the grammar rules. This wouldn't really be
an AST per se but does it really matter if we only need it for the editor?
This is very similar to the problem of importing existing lex/yacc
grammars to IMP.
Anyway, I wanted to ask you if I missed key points in my analysis. Would
you agree it's more feasible to connect Syntax to IMP (via the
interfaces you mentionned in the manual) than building a tool that'd
translate the grammar rules from Syntax to LPG?
Best regards,
--
Damien Thivolle | INRIA Rhone-Alpes / VASY
PHD Student | 655, Avenue de l'Europe
damien.thivolle@inria.fr | Montbonnot
http://www.inrialpes.fr/vasy | 38 334 Saint Ismier Cedex France
|
|
|
Re: Importing Syntax parser to IMP [message #22316 is a reply to message #21989] |
Thu, 03 July 2008 14:31 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Stan Sutton![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=suttons%40us.ibm.com) Messages: 121 Registered: July 2009 |
Senior Member |
|
|
Hello Damien,
You might very well be right. Anyway, what you suggest should work. I
can't say which approach would be easier, though. I think the main cost
of connecting Syntax to IMP may be the need to produce the AST types, as
you recognized in your post. I don't know how that cost would compare
to translating the grammars and the associated embedded code and parser
utilities.
Maybe you could try translating one of your grammars (a small one), just
to see what's involved? Or perhaps try a new language in IMP?
Some additional comments and questions are embedded in your text below.
I hope this gives you at least a little help.
Best regards,
Stan
Damien Thivolle wrote:
> Hello,
>
> In the VASY team at INRIA, we have numerous compilers in our toolbox for
> which we've used the Syntax (http://alpage.inria.fr/syntax.fr.html)
> parser generator.
>
> To build an Eclipse interface for our toolbox, we would need to somehow
> port the grammars we wrote for Syntax to IMP.
>
> I already see several problems in doing that. Syntax is C-based and we
> can embed C code in grammar rules to tune them.
You can embed Java code into LPG grammar rules. Of course, this means
you would have to translate your embedded code as well as the grammar rules.
> Also, Syntax provides
> predicates and actions that we typically use to recognize nested
> structures or handle priorities.
I gather that this is not done through the embedded code, correct? Are
these something like utility features that are provided as part of your
generated parsers? In an LPG grammar template you can specify the
import of external classes, so if the predicates and actions could be
externalized from Syntax then you could probably arrange to get them
imported into an LPG-generated parser. The language issue (C vs. Java)
applies here, too, however.
> There are other things like the
> terminals and the grammar rules being defined in different files with
> different formats. The grammar in Syntax is described with a BNF
> language while the terminals are described with regexp and operators on
> characters set.
In LPG the grammar rules and terminals are typically defined in separate
files (although they can also be combined into one). The grammar rules
are specified in some form of BNF. I'm not sure how best to
characterize the definition of terminals.
By the way, the grammar for the LPG grammar-specification language is
available in the IMP source release, in the project
org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
> Facing these problems, we thought it might be easier to connect Syntax
> to IMP (solution #2 in IMP manual). That would require a bit of hacking
> but we think it might be easier than trying to translate the grammars
> from the Syntax format to the LPG format.
We would like to believe that it is possible. To do this once for your
toolset does seem like it would be easier than translating multiple
grammars individually.
> The problem is that Syntax is written in C. I think we can implement the
> interfaces to interact with IMP but the problem is the AST. If we have
> to construct manually an AST for each grammar we're trying to port, then
> it's easier to manually port the grammar.
Yes, automatic generation of AST types is a big benefit.
> So I was thinking of
> building an AST that follows the grammar rules. This wouldn't really be
> an AST per se but does it really matter if we only need it for the editor?
This is confusing to me. Do you mean to manually build a set of AST
types? IMP doesn't care how instances of AST types are defined or
produced, so it should work fine with manually produced AST types. (IMP
generally treats AST types as Objects. Provided that the various parser
and AST-related interfaces are implemented somehow, the details of an
AST representation are important only in the language-specific
implementations of various services. And those are presumably being
provided by the same person (or group) that is providing the AST types.
The editor needs to be able to parse a source file and build an AST;
changes to the AST trigger most of the IDE services. (How the services
work--even whether they access the AST--are up to the service
implementor.) So long as you can implement the parser-related
interfaces and support this activity by the editor, that should be
sufficient.
> This is very similar to the problem of importing existing lex/yacc
> grammars to IMP.
Yes, if you have to manually produce the set of AST types for each
language it would be very similar.
> Anyway, I wanted to ask you if I missed key points in my analysis. Would
> you agree it's more feasible to connect Syntax to IMP (via the
> interfaces you mentionned in the manual) than building a tool that'd
> translate the grammar rules from Syntax to LPG?
See main note above ...
> Best regards,
>
|
|
|
Re: Importing Syntax parser to IMP [message #22512 is a reply to message #22316] |
Mon, 07 July 2008 08:41 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Stanley Sutton a écrit :
> Hello Damien,
Hello,
Thank you for your answer!
>
> You might very well be right. Anyway, what you suggest should work. I
> can't say which approach would be easier, though. I think the main cost
> of connecting Syntax to IMP may be the need to produce the AST types, as
> you recognized in your post. I don't know how that cost would compare
> to translating the grammars and the associated embedded code and parser
> utilities.
I tried to better explain this part with the AST types :)
>
> Maybe you could try translating one of your grammars (a small one), just
> to see what's involved? Or perhaps try a new language in IMP?
I've tried on a simple example (without embedded C-code nor
actions/predicates) and I had to unfold regular expressions, and other
operators on set of characters. For example in Syntax, you have
shorthand notations like "ANY" for the complete set of ASCII characters
and operators like "ANY - 'c'" for all the characters except 'c'. This
is cumbersome to write by hand the LPG grammar for a syntax grammar but
this is feasible. On the other hand, I wouldn't dare trying to translate
C code to java, there will always be cases I won't be able to treat
that's why I considered implementing the set of interfaces mentionned in
the manual.
>
> Some additional comments and questions are embedded in your text below.
> I hope this gives you at least a little help.
>
It's a really constructive exchange, thanks a lot. There are some
additional comments in the text below.
Best regards,
>
> Damien Thivolle wrote:
>> Hello,
>>
>> In the VASY team at INRIA, we have numerous compilers in our toolbox
>> for which we've used the Syntax
>> (http://alpage.inria.fr/syntax.fr.html) parser generator.
>>
>> To build an Eclipse interface for our toolbox, we would need to
>> somehow port the grammars we wrote for Syntax to IMP.
>>
>> I already see several problems in doing that. Syntax is C-based and we
>> can embed C code in grammar rules to tune them.
> You can embed Java code into LPG grammar rules. Of course, this means
> you would have to translate your embedded code as well as the grammar
> rules.
>
>> Also, Syntax provides predicates and actions that we typically use to
>> recognize nested structures or handle priorities.
> I gather that this is not done through the embedded code, correct? Are
> these something like utility features that are provided as part of your
> generated parsers? In an LPG grammar template you can specify the
> import of external classes, so if the predicates and actions could be
> externalized from Syntax then you could probably arrange to get them
> imported into an LPG-generated parser. The language issue (C vs. Java)
> applies here, too, however.
These predicates and actions allow you to manipulate counters in the
rules of the lexer. Like "&IS_SET (C)" tells you if the counter C is set
and "@RESET (C)" resets it. Let's just take an example:
COMMENTED_BLOCK = "(" "*" &true @RESET(0) {
^"(*" | "(" ^"*" | "*" ^")" |
"(" "*" @INCR(0) |
"*" ")" &IS_SET(0) @DECR(0)
} "*" ")" &IS_RESET(0);
This is typically how we'd write a lexical rule for nested comments
starting with "(*" and ending with "*)". I don't know if we can do that
with LPG.
>
>> There are other things like the terminals and the grammar rules being
>> defined in different files with different formats. The grammar in
>> Syntax is described with a BNF language while the terminals are
>> described with regexp and operators on characters set.
>
> In LPG the grammar rules and terminals are typically defined in separate
> files (although they can also be combined into one). The grammar rules
> are specified in some form of BNF. I'm not sure how best to
> characterize the definition of terminals.
>
> By the way, the grammar for the LPG grammar-specification language is
> available in the IMP source release, in the project
> org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
>
Thank you :)
>> Facing these problems, we thought it might be easier to connect Syntax
>> to IMP (solution #2 in IMP manual). That would require a bit of
>> hacking but we think it might be easier than trying to translate the
>> grammars from the Syntax format to the LPG format.
>
> We would like to believe that it is possible. To do this once for your
> toolset does seem like it would be easier than translating multiple
> grammars individually.
>
>> The problem is that Syntax is written in C. I think we can implement
>> the interfaces to interact with IMP but the problem is the AST. If we
>> have to construct manually an AST for each grammar we're trying to
>> port, then it's easier to manually port the grammar.
>
> Yes, automatic generation of AST types is a big benefit.
>
>> So I was thinking of building an AST that follows the grammar rules.
>> This wouldn't really be an AST per se but does it really matter if we
>> only need it for the editor?
>
> This is confusing to me. Do you mean to manually build a set of AST
> types? IMP doesn't care how instances of AST types are defined or
> produced, so it should work fine with manually produced AST types. (IMP
> generally treats AST types as Objects. Provided that the various parser
> and AST-related interfaces are implemented somehow, the details of an
> AST representation are important only in the language-specific
> implementations of various services. And those are presumably being
> provided by the same person (or group) that is providing the AST types.
>
As far as I understood, if we implement the set of interfaces to connect
an external parser generator to IMP, we also need to provide the AST.
The problem is that we wouldn't want to manually write the java AST
types for each of our grammars. Since we don't intend to use the java
AST for anything else than building an editor with IMP, I wanted to know
if this is reasonnable to automatically generate AST types based on the
concrete grammar. It wouldn't really be an "Abstract" syntax tree
because it would be based on the concrete syntax, but is it a problem?
> The editor needs to be able to parse a source file and build an AST;
> changes to the AST trigger most of the IDE services. (How the services
> work--even whether they access the AST--are up to the service
> implementor.) So long as you can implement the parser-related
> interfaces and support this activity by the editor, that should be
> sufficient.
>
>> This is very similar to the problem of importing existing lex/yacc
>> grammars to IMP.
>
> Yes, if you have to manually produce the set of AST types for each
> language it would be very similar.
>
>> Anyway, I wanted to ask you if I missed key points in my analysis.
>> Would you agree it's more feasible to connect Syntax to IMP (via the
>> interfaces you mentionned in the manual) than building a tool that'd
>> translate the grammar rules from Syntax to LPG?
> See main note above ...
>
>
>> Best regards,
>>
--
Damien Thivolle
|
|
|
Re: Importing Syntax parser to IMP [message #22642 is a reply to message #22512] |
Thu, 10 July 2008 14:34 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Stan Sutton![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=suttons%40us.ibm.com) Messages: 121 Registered: July 2009 |
Senior Member |
|
|
Hi Damien,
I'm glad if this has been helpful to you. Based on the additional
information, I do agree that your original idea of implementing the IMP
interfaces using Syntax seems like the most feasible approach.
Regarding your idea to automatically generate the AST types based on the
concrete syntax, I believe that should be fine. The IMP framework
doesn't care how your AST types are created or what they are based on or
what they contain--within the framework, the ASTs and AST nodes are
generally treated as objects. Where the specific nature of the AST
types becomes relevant is in the implementations of the IDE services,
which will refer to specific AST types and make use of their various
methods and fields. So the service implementor is the real user of the
AST types. As long as your generated AST types allow the services to be
implemented, that should be good enough.
Good luck! Let us know if you have any other comments or questions. We
look forward to hearing about (and learning from) your experience!
Best regards,
Stan
Damien Thivolle wrote:
> Stanley Sutton a écrit :
>> Hello Damien,
>
> Hello,
>
> Thank you for your answer!
>
>>
>> You might very well be right. Anyway, what you suggest should work.
>> I can't say which approach would be easier, though. I think the main
>> cost of connecting Syntax to IMP may be the need to produce the AST
>> types, as you recognized in your post. I don't know how that cost
>> would compare to translating the grammars and the associated embedded
>> code and parser utilities.
>
> I tried to better explain this part with the AST types :)
>
>>
>> Maybe you could try translating one of your grammars (a small one),
>> just to see what's involved? Or perhaps try a new language in IMP?
>
> I've tried on a simple example (without embedded C-code nor
> actions/predicates) and I had to unfold regular expressions, and other
> operators on set of characters. For example in Syntax, you have
> shorthand notations like "ANY" for the complete set of ASCII characters
> and operators like "ANY - 'c'" for all the characters except 'c'. This
> is cumbersome to write by hand the LPG grammar for a syntax grammar but
> this is feasible. On the other hand, I wouldn't dare trying to translate
> C code to java, there will always be cases I won't be able to treat
> that's why I considered implementing the set of interfaces mentionned in
> the manual.
>
>>
>> Some additional comments and questions are embedded in your text
>> below. I hope this gives you at least a little help.
>>
>
> It's a really constructive exchange, thanks a lot. There are some
> additional comments in the text below.
>
> Best regards,
>
>
>>
>> Damien Thivolle wrote:
>>> Hello,
>>>
>>> In the VASY team at INRIA, we have numerous compilers in our toolbox
>>> for which we've used the Syntax
>>> (http://alpage.inria.fr/syntax.fr.html) parser generator.
>>>
>>> To build an Eclipse interface for our toolbox, we would need to
>>> somehow port the grammars we wrote for Syntax to IMP.
>>>
>>> I already see several problems in doing that. Syntax is C-based and
>>> we can embed C code in grammar rules to tune them.
>> You can embed Java code into LPG grammar rules. Of course, this means
>> you would have to translate your embedded code as well as the grammar
>> rules.
>>
>>> Also, Syntax provides predicates and actions that we typically use to
>>> recognize nested structures or handle priorities.
>> I gather that this is not done through the embedded code, correct?
>> Are these something like utility features that are provided as part of
>> your generated parsers? In an LPG grammar template you can specify
>> the import of external classes, so if the predicates and actions could
>> be externalized from Syntax then you could probably arrange to get
>> them imported into an LPG-generated parser. The language issue (C vs.
>> Java) applies here, too, however.
>
>
> These predicates and actions allow you to manipulate counters in the
> rules of the lexer. Like "&IS_SET (C)" tells you if the counter C is set
> and "@RESET (C)" resets it. Let's just take an example:
>
> COMMENTED_BLOCK = "(" "*" &true @RESET(0) {
> ^"(*" | "(" ^"*" | "*" ^")" |
> "(" "*" @INCR(0) |
> "*" ")" &IS_SET(0) @DECR(0)
> } "*" ")" &IS_RESET(0);
>
>
> This is typically how we'd write a lexical rule for nested comments
> starting with "(*" and ending with "*)". I don't know if we can do that
> with LPG.
>
>>
>>> There are other things like the terminals and the grammar rules being
>>> defined in different files with different formats. The grammar in
>>> Syntax is described with a BNF language while the terminals are
>>> described with regexp and operators on characters set.
>>
>> In LPG the grammar rules and terminals are typically defined in
>> separate files (although they can also be combined into one). The
>> grammar rules are specified in some form of BNF. I'm not sure how
>> best to characterize the definition of terminals.
>>
>> By the way, the grammar for the LPG grammar-specification language is
>> available in the IMP source release, in the project
>> org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
>>
>
> Thank you :)
>
>
>>> Facing these problems, we thought it might be easier to connect
>>> Syntax to IMP (solution #2 in IMP manual). That would require a bit
>>> of hacking but we think it might be easier than trying to translate
>>> the grammars from the Syntax format to the LPG format.
>>
>> We would like to believe that it is possible. To do this once for
>> your toolset does seem like it would be easier than translating
>> multiple grammars individually.
>>
>>> The problem is that Syntax is written in C. I think we can implement
>>> the interfaces to interact with IMP but the problem is the AST. If we
>>> have to construct manually an AST for each grammar we're trying to
>>> port, then it's easier to manually port the grammar.
>>
>> Yes, automatic generation of AST types is a big benefit.
>>
>>> So I was thinking of building an AST that follows the grammar rules.
>>> This wouldn't really be an AST per se but does it really matter if we
>>> only need it for the editor?
>>
>> This is confusing to me. Do you mean to manually build a set of AST
>> types? IMP doesn't care how instances of AST types are defined or
>> produced, so it should work fine with manually produced AST types.
>> (IMP generally treats AST types as Objects. Provided that the various
>> parser and AST-related interfaces are implemented somehow, the details
>> of an AST representation are important only in the language-specific
>> implementations of various services. And those are presumably being
>> provided by the same person (or group) that is providing the AST types.
>>
>
> As far as I understood, if we implement the set of interfaces to connect
> an external parser generator to IMP, we also need to provide the AST.
> The problem is that we wouldn't want to manually write the java AST
> types for each of our grammars. Since we don't intend to use the java
> AST for anything else than building an editor with IMP, I wanted to know
> if this is reasonnable to automatically generate AST types based on the
> concrete grammar. It wouldn't really be an "Abstract" syntax tree
> because it would be based on the concrete syntax, but is it a problem?
>
>
>> The editor needs to be able to parse a source file and build an AST;
>> changes to the AST trigger most of the IDE services. (How the
>> services work--even whether they access the AST--are up to the service
>> implementor.) So long as you can implement the parser-related
>> interfaces and support this activity by the editor, that should be
>> sufficient.
>>
>>> This is very similar to the problem of importing existing lex/yacc
>>> grammars to IMP.
>>
>> Yes, if you have to manually produce the set of AST types for each
>> language it would be very similar.
>>
>>> Anyway, I wanted to ask you if I missed key points in my analysis.
>>> Would you agree it's more feasible to connect Syntax to IMP (via the
>>> interfaces you mentionned in the manual) than building a tool that'd
>>> translate the grammar rules from Syntax to LPG?
>> See main note above ...
>>
>>
>>> Best regards,
>>>
>
>
|
|
|
Re: Importing Syntax parser to IMP [message #22817 is a reply to message #22642] |
Fri, 11 July 2008 09:45 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Stanley Sutton a écrit :
> Hi Damien,
>
> I'm glad if this has been helpful to you. Based on the additional
> information, I do agree that your original idea of implementing the IMP
> interfaces using Syntax seems like the most feasible approach.
>
> Regarding your idea to automatically generate the AST types based on the
> concrete syntax, I believe that should be fine. The IMP framework
> doesn't care how your AST types are created or what they are based on or
> what they contain--within the framework, the ASTs and AST nodes are
> generally treated as objects. Where the specific nature of the AST
> types becomes relevant is in the implementations of the IDE services,
> which will refer to specific AST types and make use of their various
> methods and fields. So the service implementor is the real user of the
> AST types. As long as your generated AST types allow the services to be
> implemented, that should be good enough.
>
> Good luck! Let us know if you have any other comments or questions. We
> look forward to hearing about (and learning from) your experience!
>
> Best regards,
>
Hello,
Thanks for your answer.
We still have not yet decided which method we will implement.
We are wondering how to solve conflicts with IMP. Are there any ways to
specify priorities or to handle conflict resolution?
For instance, if I have a grammar E ::= E + E | E * E | N. How can I
tell IMP that * has a higher priority than +?
Also, for shift-reduce conflicts, is it possible to tell IMP whether to
shift or reduce for a particular conflict appear.
I did not see any mention of this in the manual. Does it mean it is not
possible to do it?
Best regards,
--
Damien Thivolle | INRIA Rhone-Alpes / VASY
PHD Student | 655, Avenue de l'Europe
damien.thivolle@inria.fr | Montbonnot
http://www.inrialpes.fr/vasy | 38 334 Saint Ismier Cedex France
|
|
|
Re: Importing Syntax parser to IMP [message #22861 is a reply to message #22817] |
Fri, 11 July 2008 22:49 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: regenmacher.online.de
"Damien Thivolle" <damien.thivolle@inria.fr> schrieb im Newsbeitrag
news:g57a3f$kfn$1@build.eclipse.org...
> Stanley Sutton a écrit :
>> Hi Damien,
>>
>> I'm glad if this has been helpful to you. Based on the additional
>> information, I do agree that your original idea of implementing the IMP
>> interfaces using Syntax seems like the most feasible approach.
>>
>> Regarding your idea to automatically generate the AST types based on the
>> concrete syntax, I believe that should be fine. The IMP framework
>> doesn't care how your AST types are created or what they are based on or
>> what they contain--within the framework, the ASTs and AST nodes are
>> generally treated as objects. Where the specific nature of the AST types
>> becomes relevant is in the implementations of the IDE services, which
>> will refer to specific AST types and make use of their various methods
>> and fields. So the service implementor is the real user of the AST
>> types. As long as your generated AST types allow the services to be
>> implemented, that should be good enough.
>>
>> Good luck! Let us know if you have any other comments or questions. We
>> look forward to hearing about (and learning from) your experience!
>>
>> Best regards,
>>
>
> Hello,
>
> Thanks for your answer.
>
> We still have not yet decided which method we will implement.
>
> We are wondering how to solve conflicts with IMP. Are there any ways to
> specify priorities or to handle conflict resolution?
>
> For instance, if I have a grammar E ::= E + E | E * E | N. How can I tell
> IMP that * has a higher priority than +?
>
> Also, for shift-reduce conflicts, is it possible to tell IMP whether to
> shift or reduce for a particular conflict appear.
>
> I did not see any mention of this in the manual. Does it mean it is not
> possible to do it?
>
> Best regards,
>
> --
> Damien Thivolle | INRIA Rhone-Alpes / VASY
This are LPG-centric-questions, one solution is to reformulate/fix your
grammar, using separate non-terminals for the two precedence-levels.
Here is a simple reformulation:
E ::= E '+' M | M
M ::= M '*' N | N
Im not a LPG-expert - I am not aware of any explicit precedence-rule in LPG,
that solves precedence-problems.
Explicit precedence-rules could be used to solve shift/reduce-conflicts.
May be fitting the grammar to solve the conflict is a better idea ??
michael
|
|
|
Re: Importing Syntax parser to IMP [message #22991 is a reply to message #22861] |
Wed, 16 July 2008 16:53 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Michael Strothjohann a écrit :
>
> "Damien Thivolle" <damien.thivolle@inria.fr> schrieb im Newsbeitrag
> news:g57a3f$kfn$1@build.eclipse.org...
>> Stanley Sutton a écrit :
>>> Hi Damien,
>>>
>>> I'm glad if this has been helpful to you. Based on the additional
>>> information, I do agree that your original idea of implementing the
>>> IMP interfaces using Syntax seems like the most feasible approach.
>>>
>>> Regarding your idea to automatically generate the AST types based on
>>> the concrete syntax, I believe that should be fine. The IMP
>>> framework doesn't care how your AST types are created or what they
>>> are based on or what they contain--within the framework, the ASTs and
>>> AST nodes are generally treated as objects. Where the specific
>>> nature of the AST types becomes relevant is in the implementations of
>>> the IDE services, which will refer to specific AST types and make use
>>> of their various methods and fields. So the service implementor is
>>> the real user of the AST types. As long as your generated AST types
>>> allow the services to be implemented, that should be good enough.
>>>
>>> Good luck! Let us know if you have any other comments or questions.
>>> We look forward to hearing about (and learning from) your experience!
>>>
>>> Best regards,
>>>
>>
>> Hello,
>>
>> Thanks for your answer.
>>
>> We still have not yet decided which method we will implement.
>>
>> We are wondering how to solve conflicts with IMP. Are there any ways
>> to specify priorities or to handle conflict resolution?
>>
>> For instance, if I have a grammar E ::= E + E | E * E | N. How can I
>> tell IMP that * has a higher priority than +?
>>
>> Also, for shift-reduce conflicts, is it possible to tell IMP whether
>> to shift or reduce for a particular conflict appear.
>>
>> I did not see any mention of this in the manual. Does it mean it is
>> not possible to do it?
>>
>> Best regards,
>>
>> --
>> Damien Thivolle | INRIA Rhone-Alpes / VASY
>
>
> This are LPG-centric-questions, one solution is to reformulate/fix your
> grammar, using separate non-terminals for the two precedence-levels.
> Here is a simple reformulation:
>
> E ::= E '+' M | M
> M ::= M '*' N | N
>
> Im not a LPG-expert - I am not aware of any explicit precedence-rule in
> LPG, that solves precedence-problems.
> Explicit precedence-rules could be used to solve shift/reduce-conflicts.
> May be fitting the grammar to solve the conflict is a better idea ??
>
> michael
Thank you for your answer.
I want to automate the translation of grammars from the SYNTAX format to
the LPG format. I don't think I can afford to write a translator that
would disambiguate a grammar :(
--
Damien Thivolle | INRIA Rhone-Alpes / VASY
PHD Student | 655, Avenue de l'Europe
damien.thivolle@inria.fr | Montbonnot
http://www.inrialpes.fr/vasy | 38 334 Saint Ismier Cedex France
|
|
| |
Re: Importing Syntax parser to IMP [message #572033 is a reply to message #21989] |
Thu, 03 July 2008 14:31 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Stan Sutton![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=suttons%40us.ibm.com) Messages: 121 Registered: July 2009 |
Senior Member |
|
|
Hello Damien,
You might very well be right. Anyway, what you suggest should work. I
can't say which approach would be easier, though. I think the main cost
of connecting Syntax to IMP may be the need to produce the AST types, as
you recognized in your post. I don't know how that cost would compare
to translating the grammars and the associated embedded code and parser
utilities.
Maybe you could try translating one of your grammars (a small one), just
to see what's involved? Or perhaps try a new language in IMP?
Some additional comments and questions are embedded in your text below.
I hope this gives you at least a little help.
Best regards,
Stan
Damien Thivolle wrote:
> Hello,
>
> In the VASY team at INRIA, we have numerous compilers in our toolbox for
> which we've used the Syntax (http://alpage.inria.fr/syntax.fr.html)
> parser generator.
>
> To build an Eclipse interface for our toolbox, we would need to somehow
> port the grammars we wrote for Syntax to IMP.
>
> I already see several problems in doing that. Syntax is C-based and we
> can embed C code in grammar rules to tune them.
You can embed Java code into LPG grammar rules. Of course, this means
you would have to translate your embedded code as well as the grammar rules.
> Also, Syntax provides
> predicates and actions that we typically use to recognize nested
> structures or handle priorities.
I gather that this is not done through the embedded code, correct? Are
these something like utility features that are provided as part of your
generated parsers? In an LPG grammar template you can specify the
import of external classes, so if the predicates and actions could be
externalized from Syntax then you could probably arrange to get them
imported into an LPG-generated parser. The language issue (C vs. Java)
applies here, too, however.
> There are other things like the
> terminals and the grammar rules being defined in different files with
> different formats. The grammar in Syntax is described with a BNF
> language while the terminals are described with regexp and operators on
> characters set.
In LPG the grammar rules and terminals are typically defined in separate
files (although they can also be combined into one). The grammar rules
are specified in some form of BNF. I'm not sure how best to
characterize the definition of terminals.
By the way, the grammar for the LPG grammar-specification language is
available in the IMP source release, in the project
org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
> Facing these problems, we thought it might be easier to connect Syntax
> to IMP (solution #2 in IMP manual). That would require a bit of hacking
> but we think it might be easier than trying to translate the grammars
> from the Syntax format to the LPG format.
We would like to believe that it is possible. To do this once for your
toolset does seem like it would be easier than translating multiple
grammars individually.
> The problem is that Syntax is written in C. I think we can implement the
> interfaces to interact with IMP but the problem is the AST. If we have
> to construct manually an AST for each grammar we're trying to port, then
> it's easier to manually port the grammar.
Yes, automatic generation of AST types is a big benefit.
> So I was thinking of
> building an AST that follows the grammar rules. This wouldn't really be
> an AST per se but does it really matter if we only need it for the editor?
This is confusing to me. Do you mean to manually build a set of AST
types? IMP doesn't care how instances of AST types are defined or
produced, so it should work fine with manually produced AST types. (IMP
generally treats AST types as Objects. Provided that the various parser
and AST-related interfaces are implemented somehow, the details of an
AST representation are important only in the language-specific
implementations of various services. And those are presumably being
provided by the same person (or group) that is providing the AST types.
The editor needs to be able to parse a source file and build an AST;
changes to the AST trigger most of the IDE services. (How the services
work--even whether they access the AST--are up to the service
implementor.) So long as you can implement the parser-related
interfaces and support this activity by the editor, that should be
sufficient.
> This is very similar to the problem of importing existing lex/yacc
> grammars to IMP.
Yes, if you have to manually produce the set of AST types for each
language it would be very similar.
> Anyway, I wanted to ask you if I missed key points in my analysis. Would
> you agree it's more feasible to connect Syntax to IMP (via the
> interfaces you mentionned in the manual) than building a tool that'd
> translate the grammar rules from Syntax to LPG?
See main note above ...
> Best regards,
>
|
|
|
Re: Importing Syntax parser to IMP [message #572184 is a reply to message #22316] |
Mon, 07 July 2008 08:41 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Stanley Sutton a écrit :
> Hello Damien,
Hello,
Thank you for your answer!
>
> You might very well be right. Anyway, what you suggest should work. I
> can't say which approach would be easier, though. I think the main cost
> of connecting Syntax to IMP may be the need to produce the AST types, as
> you recognized in your post. I don't know how that cost would compare
> to translating the grammars and the associated embedded code and parser
> utilities.
I tried to better explain this part with the AST types :)
>
> Maybe you could try translating one of your grammars (a small one), just
> to see what's involved? Or perhaps try a new language in IMP?
I've tried on a simple example (without embedded C-code nor
actions/predicates) and I had to unfold regular expressions, and other
operators on set of characters. For example in Syntax, you have
shorthand notations like "ANY" for the complete set of ASCII characters
and operators like "ANY - 'c'" for all the characters except 'c'. This
is cumbersome to write by hand the LPG grammar for a syntax grammar but
this is feasible. On the other hand, I wouldn't dare trying to translate
C code to java, there will always be cases I won't be able to treat
that's why I considered implementing the set of interfaces mentionned in
the manual.
>
> Some additional comments and questions are embedded in your text below.
> I hope this gives you at least a little help.
>
It's a really constructive exchange, thanks a lot. There are some
additional comments in the text below.
Best regards,
>
> Damien Thivolle wrote:
>> Hello,
>>
>> In the VASY team at INRIA, we have numerous compilers in our toolbox
>> for which we've used the Syntax
>> (http://alpage.inria.fr/syntax.fr.html) parser generator.
>>
>> To build an Eclipse interface for our toolbox, we would need to
>> somehow port the grammars we wrote for Syntax to IMP.
>>
>> I already see several problems in doing that. Syntax is C-based and we
>> can embed C code in grammar rules to tune them.
> You can embed Java code into LPG grammar rules. Of course, this means
> you would have to translate your embedded code as well as the grammar
> rules.
>
>> Also, Syntax provides predicates and actions that we typically use to
>> recognize nested structures or handle priorities.
> I gather that this is not done through the embedded code, correct? Are
> these something like utility features that are provided as part of your
> generated parsers? In an LPG grammar template you can specify the
> import of external classes, so if the predicates and actions could be
> externalized from Syntax then you could probably arrange to get them
> imported into an LPG-generated parser. The language issue (C vs. Java)
> applies here, too, however.
These predicates and actions allow you to manipulate counters in the
rules of the lexer. Like "&IS_SET (C)" tells you if the counter C is set
and "@RESET (C)" resets it. Let's just take an example:
COMMENTED_BLOCK = "(" "*" &true @RESET(0) {
^"(*" | "(" ^"*" | "*" ^")" |
"(" "*" @INCR(0) |
"*" ")" &IS_SET(0) @DECR(0)
} "*" ")" &IS_RESET(0);
This is typically how we'd write a lexical rule for nested comments
starting with "(*" and ending with "*)". I don't know if we can do that
with LPG.
>
>> There are other things like the terminals and the grammar rules being
>> defined in different files with different formats. The grammar in
>> Syntax is described with a BNF language while the terminals are
>> described with regexp and operators on characters set.
>
> In LPG the grammar rules and terminals are typically defined in separate
> files (although they can also be combined into one). The grammar rules
> are specified in some form of BNF. I'm not sure how best to
> characterize the definition of terminals.
>
> By the way, the grammar for the LPG grammar-specification language is
> available in the IMP source release, in the project
> org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
>
Thank you :)
>> Facing these problems, we thought it might be easier to connect Syntax
>> to IMP (solution #2 in IMP manual). That would require a bit of
>> hacking but we think it might be easier than trying to translate the
>> grammars from the Syntax format to the LPG format.
>
> We would like to believe that it is possible. To do this once for your
> toolset does seem like it would be easier than translating multiple
> grammars individually.
>
>> The problem is that Syntax is written in C. I think we can implement
>> the interfaces to interact with IMP but the problem is the AST. If we
>> have to construct manually an AST for each grammar we're trying to
>> port, then it's easier to manually port the grammar.
>
> Yes, automatic generation of AST types is a big benefit.
>
>> So I was thinking of building an AST that follows the grammar rules.
>> This wouldn't really be an AST per se but does it really matter if we
>> only need it for the editor?
>
> This is confusing to me. Do you mean to manually build a set of AST
> types? IMP doesn't care how instances of AST types are defined or
> produced, so it should work fine with manually produced AST types. (IMP
> generally treats AST types as Objects. Provided that the various parser
> and AST-related interfaces are implemented somehow, the details of an
> AST representation are important only in the language-specific
> implementations of various services. And those are presumably being
> provided by the same person (or group) that is providing the AST types.
>
As far as I understood, if we implement the set of interfaces to connect
an external parser generator to IMP, we also need to provide the AST.
The problem is that we wouldn't want to manually write the java AST
types for each of our grammars. Since we don't intend to use the java
AST for anything else than building an editor with IMP, I wanted to know
if this is reasonnable to automatically generate AST types based on the
concrete grammar. It wouldn't really be an "Abstract" syntax tree
because it would be based on the concrete syntax, but is it a problem?
> The editor needs to be able to parse a source file and build an AST;
> changes to the AST trigger most of the IDE services. (How the services
> work--even whether they access the AST--are up to the service
> implementor.) So long as you can implement the parser-related
> interfaces and support this activity by the editor, that should be
> sufficient.
>
>> This is very similar to the problem of importing existing lex/yacc
>> grammars to IMP.
>
> Yes, if you have to manually produce the set of AST types for each
> language it would be very similar.
>
>> Anyway, I wanted to ask you if I missed key points in my analysis.
>> Would you agree it's more feasible to connect Syntax to IMP (via the
>> interfaces you mentionned in the manual) than building a tool that'd
>> translate the grammar rules from Syntax to LPG?
> See main note above ...
>
>
>> Best regards,
>>
--
Damien Thivolle
|
|
|
Re: Importing Syntax parser to IMP [message #572246 is a reply to message #22512] |
Thu, 10 July 2008 14:34 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Stan Sutton![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=suttons%40us.ibm.com) Messages: 121 Registered: July 2009 |
Senior Member |
|
|
Hi Damien,
I'm glad if this has been helpful to you. Based on the additional
information, I do agree that your original idea of implementing the IMP
interfaces using Syntax seems like the most feasible approach.
Regarding your idea to automatically generate the AST types based on the
concrete syntax, I believe that should be fine. The IMP framework
doesn't care how your AST types are created or what they are based on or
what they contain--within the framework, the ASTs and AST nodes are
generally treated as objects. Where the specific nature of the AST
types becomes relevant is in the implementations of the IDE services,
which will refer to specific AST types and make use of their various
methods and fields. So the service implementor is the real user of the
AST types. As long as your generated AST types allow the services to be
implemented, that should be good enough.
Good luck! Let us know if you have any other comments or questions. We
look forward to hearing about (and learning from) your experience!
Best regards,
Stan
Damien Thivolle wrote:
> Stanley Sutton a écrit :
>> Hello Damien,
>
> Hello,
>
> Thank you for your answer!
>
>>
>> You might very well be right. Anyway, what you suggest should work.
>> I can't say which approach would be easier, though. I think the main
>> cost of connecting Syntax to IMP may be the need to produce the AST
>> types, as you recognized in your post. I don't know how that cost
>> would compare to translating the grammars and the associated embedded
>> code and parser utilities.
>
> I tried to better explain this part with the AST types :)
>
>>
>> Maybe you could try translating one of your grammars (a small one),
>> just to see what's involved? Or perhaps try a new language in IMP?
>
> I've tried on a simple example (without embedded C-code nor
> actions/predicates) and I had to unfold regular expressions, and other
> operators on set of characters. For example in Syntax, you have
> shorthand notations like "ANY" for the complete set of ASCII characters
> and operators like "ANY - 'c'" for all the characters except 'c'. This
> is cumbersome to write by hand the LPG grammar for a syntax grammar but
> this is feasible. On the other hand, I wouldn't dare trying to translate
> C code to java, there will always be cases I won't be able to treat
> that's why I considered implementing the set of interfaces mentionned in
> the manual.
>
>>
>> Some additional comments and questions are embedded in your text
>> below. I hope this gives you at least a little help.
>>
>
> It's a really constructive exchange, thanks a lot. There are some
> additional comments in the text below.
>
> Best regards,
>
>
>>
>> Damien Thivolle wrote:
>>> Hello,
>>>
>>> In the VASY team at INRIA, we have numerous compilers in our toolbox
>>> for which we've used the Syntax
>>> (http://alpage.inria.fr/syntax.fr.html) parser generator.
>>>
>>> To build an Eclipse interface for our toolbox, we would need to
>>> somehow port the grammars we wrote for Syntax to IMP.
>>>
>>> I already see several problems in doing that. Syntax is C-based and
>>> we can embed C code in grammar rules to tune them.
>> You can embed Java code into LPG grammar rules. Of course, this means
>> you would have to translate your embedded code as well as the grammar
>> rules.
>>
>>> Also, Syntax provides predicates and actions that we typically use to
>>> recognize nested structures or handle priorities.
>> I gather that this is not done through the embedded code, correct?
>> Are these something like utility features that are provided as part of
>> your generated parsers? In an LPG grammar template you can specify
>> the import of external classes, so if the predicates and actions could
>> be externalized from Syntax then you could probably arrange to get
>> them imported into an LPG-generated parser. The language issue (C vs.
>> Java) applies here, too, however.
>
>
> These predicates and actions allow you to manipulate counters in the
> rules of the lexer. Like "&IS_SET (C)" tells you if the counter C is set
> and "@RESET (C)" resets it. Let's just take an example:
>
> COMMENTED_BLOCK = "(" "*" &true @RESET(0) {
> ^"(*" | "(" ^"*" | "*" ^")" |
> "(" "*" @INCR(0) |
> "*" ")" &IS_SET(0) @DECR(0)
> } "*" ")" &IS_RESET(0);
>
>
> This is typically how we'd write a lexical rule for nested comments
> starting with "(*" and ending with "*)". I don't know if we can do that
> with LPG.
>
>>
>>> There are other things like the terminals and the grammar rules being
>>> defined in different files with different formats. The grammar in
>>> Syntax is described with a BNF language while the terminals are
>>> described with regexp and operators on characters set.
>>
>> In LPG the grammar rules and terminals are typically defined in
>> separate files (although they can also be combined into one). The
>> grammar rules are specified in some form of BNF. I'm not sure how
>> best to characterize the definition of terminals.
>>
>> By the way, the grammar for the LPG grammar-specification language is
>> available in the IMP source release, in the project
>> org.eclipse.imp.lpg.runtime, in the org.eclipse.imp.lpg.parser package.
>>
>
> Thank you :)
>
>
>>> Facing these problems, we thought it might be easier to connect
>>> Syntax to IMP (solution #2 in IMP manual). That would require a bit
>>> of hacking but we think it might be easier than trying to translate
>>> the grammars from the Syntax format to the LPG format.
>>
>> We would like to believe that it is possible. To do this once for
>> your toolset does seem like it would be easier than translating
>> multiple grammars individually.
>>
>>> The problem is that Syntax is written in C. I think we can implement
>>> the interfaces to interact with IMP but the problem is the AST. If we
>>> have to construct manually an AST for each grammar we're trying to
>>> port, then it's easier to manually port the grammar.
>>
>> Yes, automatic generation of AST types is a big benefit.
>>
>>> So I was thinking of building an AST that follows the grammar rules.
>>> This wouldn't really be an AST per se but does it really matter if we
>>> only need it for the editor?
>>
>> This is confusing to me. Do you mean to manually build a set of AST
>> types? IMP doesn't care how instances of AST types are defined or
>> produced, so it should work fine with manually produced AST types.
>> (IMP generally treats AST types as Objects. Provided that the various
>> parser and AST-related interfaces are implemented somehow, the details
>> of an AST representation are important only in the language-specific
>> implementations of various services. And those are presumably being
>> provided by the same person (or group) that is providing the AST types.
>>
>
> As far as I understood, if we implement the set of interfaces to connect
> an external parser generator to IMP, we also need to provide the AST.
> The problem is that we wouldn't want to manually write the java AST
> types for each of our grammars. Since we don't intend to use the java
> AST for anything else than building an editor with IMP, I wanted to know
> if this is reasonnable to automatically generate AST types based on the
> concrete grammar. It wouldn't really be an "Abstract" syntax tree
> because it would be based on the concrete syntax, but is it a problem?
>
>
>> The editor needs to be able to parse a source file and build an AST;
>> changes to the AST trigger most of the IDE services. (How the
>> services work--even whether they access the AST--are up to the service
>> implementor.) So long as you can implement the parser-related
>> interfaces and support this activity by the editor, that should be
>> sufficient.
>>
>>> This is very similar to the problem of importing existing lex/yacc
>>> grammars to IMP.
>>
>> Yes, if you have to manually produce the set of AST types for each
>> language it would be very similar.
>>
>>> Anyway, I wanted to ask you if I missed key points in my analysis.
>>> Would you agree it's more feasible to connect Syntax to IMP (via the
>>> interfaces you mentionned in the manual) than building a tool that'd
>>> translate the grammar rules from Syntax to LPG?
>> See main note above ...
>>
>>
>>> Best regards,
>>>
>
>
|
|
|
Re: Importing Syntax parser to IMP [message #572335 is a reply to message #22642] |
Fri, 11 July 2008 09:45 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Stanley Sutton a écrit :
> Hi Damien,
>
> I'm glad if this has been helpful to you. Based on the additional
> information, I do agree that your original idea of implementing the IMP
> interfaces using Syntax seems like the most feasible approach.
>
> Regarding your idea to automatically generate the AST types based on the
> concrete syntax, I believe that should be fine. The IMP framework
> doesn't care how your AST types are created or what they are based on or
> what they contain--within the framework, the ASTs and AST nodes are
> generally treated as objects. Where the specific nature of the AST
> types becomes relevant is in the implementations of the IDE services,
> which will refer to specific AST types and make use of their various
> methods and fields. So the service implementor is the real user of the
> AST types. As long as your generated AST types allow the services to be
> implemented, that should be good enough.
>
> Good luck! Let us know if you have any other comments or questions. We
> look forward to hearing about (and learning from) your experience!
>
> Best regards,
>
Hello,
Thanks for your answer.
We still have not yet decided which method we will implement.
We are wondering how to solve conflicts with IMP. Are there any ways to
specify priorities or to handle conflict resolution?
For instance, if I have a grammar E ::= E + E | E * E | N. How can I
tell IMP that * has a higher priority than +?
Also, for shift-reduce conflicts, is it possible to tell IMP whether to
shift or reduce for a particular conflict appear.
I did not see any mention of this in the manual. Does it mean it is not
possible to do it?
Best regards,
--
Damien Thivolle | INRIA Rhone-Alpes / VASY
PHD Student | 655, Avenue de l'Europe
damien.thivolle@inria.fr | Montbonnot
http://www.inrialpes.fr/vasy | 38 334 Saint Ismier Cedex France
|
|
|
Re: Importing Syntax parser to IMP [message #572402 is a reply to message #22817] |
Fri, 11 July 2008 22:49 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Michael Strothjohann![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=strothjohann%40strothjohann.de) Messages: 52 Registered: July 2009 |
Member |
|
|
"Damien Thivolle" <damien.thivolle@inria.fr> schrieb im Newsbeitrag
news:g57a3f$kfn$1@build.eclipse.org...
> Stanley Sutton a écrit :
>> Hi Damien,
>>
>> I'm glad if this has been helpful to you. Based on the additional
>> information, I do agree that your original idea of implementing the IMP
>> interfaces using Syntax seems like the most feasible approach.
>>
>> Regarding your idea to automatically generate the AST types based on the
>> concrete syntax, I believe that should be fine. The IMP framework
>> doesn't care how your AST types are created or what they are based on or
>> what they contain--within the framework, the ASTs and AST nodes are
>> generally treated as objects. Where the specific nature of the AST types
>> becomes relevant is in the implementations of the IDE services, which
>> will refer to specific AST types and make use of their various methods
>> and fields. So the service implementor is the real user of the AST
>> types. As long as your generated AST types allow the services to be
>> implemented, that should be good enough.
>>
>> Good luck! Let us know if you have any other comments or questions. We
>> look forward to hearing about (and learning from) your experience!
>>
>> Best regards,
>>
>
> Hello,
>
> Thanks for your answer.
>
> We still have not yet decided which method we will implement.
>
> We are wondering how to solve conflicts with IMP. Are there any ways to
> specify priorities or to handle conflict resolution?
>
> For instance, if I have a grammar E ::= E + E | E * E | N. How can I tell
> IMP that * has a higher priority than +?
>
> Also, for shift-reduce conflicts, is it possible to tell IMP whether to
> shift or reduce for a particular conflict appear.
>
> I did not see any mention of this in the manual. Does it mean it is not
> possible to do it?
>
> Best regards,
>
> --
> Damien Thivolle | INRIA Rhone-Alpes / VASY
This are LPG-centric-questions, one solution is to reformulate/fix your
grammar, using separate non-terminals for the two precedence-levels.
Here is a simple reformulation:
E ::= E '+' M | M
M ::= M '*' N | N
Im not a LPG-expert - I am not aware of any explicit precedence-rule in LPG,
that solves precedence-problems.
Explicit precedence-rules could be used to solve shift/reduce-conflicts.
May be fitting the grammar to solve the conflict is a better idea ??
michael
|
|
|
Re: Importing Syntax parser to IMP [message #572466 is a reply to message #22861] |
Wed, 16 July 2008 16:53 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Damien Thivolle![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=damien.thivolle%40inria.fr) Messages: 25 Registered: July 2009 |
Junior Member |
|
|
Michael Strothjohann a écrit :
>
> "Damien Thivolle" <damien.thivolle@inria.fr> schrieb im Newsbeitrag
> news:g57a3f$kfn$1@build.eclipse.org...
>> Stanley Sutton a écrit :
>>> Hi Damien,
>>>
>>> I'm glad if this has been helpful to you. Based on the additional
>>> information, I do agree that your original idea of implementing the
>>> IMP interfaces using Syntax seems like the most feasible approach.
>>>
>>> Regarding your idea to automatically generate the AST types based on
>>> the concrete syntax, I believe that should be fine. The IMP
>>> framework doesn't care how your AST types are created or what they
>>> are based on or what they contain--within the framework, the ASTs and
>>> AST nodes are generally treated as objects. Where the specific
>>> nature of the AST types becomes relevant is in the implementations of
>>> the IDE services, which will refer to specific AST types and make use
>>> of their various methods and fields. So the service implementor is
>>> the real user of the AST types. As long as your generated AST types
>>> allow the services to be implemented, that should be good enough.
>>>
>>> Good luck! Let us know if you have any other comments or questions.
>>> We look forward to hearing about (and learning from) your experience!
>>>
>>> Best regards,
>>>
>>
>> Hello,
>>
>> Thanks for your answer.
>>
>> We still have not yet decided which method we will implement.
>>
>> We are wondering how to solve conflicts with IMP. Are there any ways
>> to specify priorities or to handle conflict resolution?
>>
>> For instance, if I have a grammar E ::= E + E | E * E | N. How can I
>> tell IMP that * has a higher priority than +?
>>
>> Also, for shift-reduce conflicts, is it possible to tell IMP whether
>> to shift or reduce for a particular conflict appear.
>>
>> I did not see any mention of this in the manual. Does it mean it is
>> not possible to do it?
>>
>> Best regards,
>>
>> --
>> Damien Thivolle | INRIA Rhone-Alpes / VASY
>
>
> This are LPG-centric-questions, one solution is to reformulate/fix your
> grammar, using separate non-terminals for the two precedence-levels.
> Here is a simple reformulation:
>
> E ::= E '+' M | M
> M ::= M '*' N | N
>
> Im not a LPG-expert - I am not aware of any explicit precedence-rule in
> LPG, that solves precedence-problems.
> Explicit precedence-rules could be used to solve shift/reduce-conflicts.
> May be fitting the grammar to solve the conflict is a better idea ??
>
> michael
Thank you for your answer.
I want to automate the translation of grammars from the SYNTAX format to
the LPG format. I don't think I can afford to write a translator that
would disambiguate a grammar :(
--
Damien Thivolle | INRIA Rhone-Alpes / VASY
PHD Student | 655, Avenue de l'Europe
damien.thivolle@inria.fr | Montbonnot
http://www.inrialpes.fr/vasy | 38 334 Saint Ismier Cedex France
|
|
| |
Goto Forum:
Current Time: Wed Sep 04 21:36:49 GMT 2024
Powered by FUDForum. Page generated in 0.05176 seconds
|