Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » best approach integrating emft ocl?
| best approach integrating emft ocl? [message #31983] |
Wed, 19 April 2006 04:21  |
Eclipse User |
|
|
|
Originally posted by: jgreen.upb.de
Hi,
This is a rather general question.
If I have an application using EMFT OCL and would like to create a text parser for that application (that parses my
stuff and OCL), what would be the best approach to this. I'm pretty new to EMFT and unexperienced ANTLR, so I seek some
advice to point me in the right direction.
Thanks
Joel
|
|
|
| Re: best approach integrating emft ocl? [message #32053 is a reply to message #31983] |
Wed, 19 April 2006 09:09  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
Perhaps we can narrow the parameters of your question a little.
First, I should mention that ANTLR is now irrelevant; the OCL parser is
generated by LPG (the LALR Parser Generator project on SourceForge).
Do you mean that you will have text documents that mix OCL with another
language, and you want to parse the OCL bits using EMFT? That should be
fairly straightforward, as long as you can extract the OCL expressions and
feed them into either the IOCLHelper API or using the internal OCLParser
class if you want to include the context declaration syntax.
If you want to extend the OCL grammar (and, therefore, the parser) to parse
the OCL together with the rest of your text, then that is a more complex
proposition. This effectively rewrites or extends a considerable
proportion of the code in the org.eclipse.emf.ocl.internal.parser package.
The LPG project should be making documentation available that will help you
to get started with their parser generator
(http://sourceforge.net/projects/lpg).
Cheers,
Christian
Joel Greenyer wrote:
> Hi,
> This is a rather general question.
>
> If I have an application using EMFT OCL and would like to create a text
> parser for that application (that parses my stuff and OCL), what would be
> the best approach to this. I'm pretty new to EMFT and unexperienced ANTLR,
> so I seek some advice to point me in the right direction.
>
> Thanks
>
> Joel
|
|
|
| Re: best approach integrating emft ocl? [message #32088 is a reply to message #32053] |
Thu, 20 April 2006 10:26 |
| Eclipse User |
|
|
|
Originally posted by: jgreen.upb.de
Christian,
I will have a document that has OCL statements in it, so it's the first of the two cases that you described.
So, technically, in some parts of the grammar, I have an OCLEpression and from there on, the OCLParser should to do its
work.
I'm now working myself into LPG... unfortunately the documentation is not as thorough as for ANTLR.
Well, maybe this is not so EMFT specific, but what I could use is some advice on how to extend the ocl lexer/parser.
Or do you know of any documentation/examples available?
Thanks
Joel
Christian W. Damus wrote:
> Hi, Joel,
>
> Perhaps we can narrow the parameters of your question a little.
>
> First, I should mention that ANTLR is now irrelevant; the OCL parser is
> generated by LPG (the LALR Parser Generator project on SourceForge).
>
> Do you mean that you will have text documents that mix OCL with another
> language, and you want to parse the OCL bits using EMFT? That should be
> fairly straightforward, as long as you can extract the OCL expressions and
> feed them into either the IOCLHelper API or using the internal OCLParser
> class if you want to include the context declaration syntax.
>
> If you want to extend the OCL grammar (and, therefore, the parser) to parse
> the OCL together with the rest of your text, then that is a more complex
> proposition. This effectively rewrites or extends a considerable
> proportion of the code in the org.eclipse.emf.ocl.internal.parser package.
> The LPG project should be making documentation available that will help you
> to get started with their parser generator
> (http://sourceforge.net/projects/lpg).
>
> Cheers,
>
> Christian
>
>
> Joel Greenyer wrote:
>
>> Hi,
>> This is a rather general question.
>>
>> If I have an application using EMFT OCL and would like to create a text
>> parser for that application (that parses my stuff and OCL), what would be
>> the best approach to this. I'm pretty new to EMFT and unexperienced ANTLR,
>> so I seek some advice to point me in the right direction.
>>
>> Thanks
>>
>> Joel
>
|
|
|
| Re: best approach integrating emft ocl? [message #32544 is a reply to message #32088] |
Fri, 21 April 2006 08:14 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
Unfortunately, the OCL lexer/parser was not designed to be extensible. I
think that you would be able to define .g files (LPG uses the same file
extension as ANTLR) that "include" rules from EMFT's OCL grammar, but I
don't know that LPG supports redefinition of rules by an extending grammar.
I think that you would have to generate a lexer and parser that either
extend the existing OCLLexer and OCLParser classes or replace them, from
some modified version of our .g files. I'm afraid that I don't know the
LPG system well enough, myself, to offer much advice ... I'm still quite
new to it.
However, if you can "call out" to the EMFT OCL parser for the OCL fragments
in your document, extending the OCL parser should only be necessary if you
need to extend the OCL language for your application. Is that the case?
The only examples that I know of for LPG (besides OCL, of course) are those
shipped with LPG, which include a Java grammer, a "little expression
grammar" for arithmetic expressions, and (in the LPG source) the grammar
for LPG's .g files.
Cheers,
Christian
Joel Greenyer wrote:
> Christian,
> I will have a document that has OCL statements in it, so it's the first of
> the two cases that you described. So, technically, in some parts of the
> grammar, I have an OCLEpression and from there on, the OCLParser should to
> do its work.
>
> I'm now working myself into LPG... unfortunately the documentation is not
> as thorough as for ANTLR.
>
> Well, maybe this is not so EMFT specific, but what I could use is some
> advice on how to extend the ocl lexer/parser. Or do you know of any
> documentation/examples available?
>
> Thanks
>
> Joel
<snip>
|
|
|
| Re: best approach integrating emft ocl? [message #32578 is a reply to message #32544] |
Fri, 21 April 2006 08:55 |
| Eclipse User |
|
|
|
Originally posted by: jgreen.upb.de
Christian W. Damus wrote:
> Hi, Joel,
>
> Unfortunately, the OCL lexer/parser was not designed to be extensible. I
> think that you would be able to define .g files (LPG uses the same file
> extension as ANTLR) that "include" rules from EMFT's OCL grammar, but I
> don't know that LPG supports redefinition of rules by an extending grammar.
> I think that you would have to generate a lexer and parser that either
> extend the existing OCLLexer and OCLParser classes or replace them, from
> some modified version of our .g files. I'm afraid that I don't know the
> LPG system well enough, myself, to offer much advice ... I'm still quite
> new to it.
>
> However, if you can "call out" to the EMFT OCL parser for the OCL fragments
> in your document, extending the OCL parser should only be necessary if you
> need to extend the OCL language for your application. Is that the case?
No, I won't extend OCL itself.
I'll consider your thoughts on this. If I'll come up with a -good- solution,
I'll probably share it here.
(Maybe something like this (http://www.eclipsecon.org/2006/Sub.do?id=438) could
make life a bit easier some day.)
Thanks so far!
Joel
>
> The only examples that I know of for LPG (besides OCL, of course) are those
> shipped with LPG, which include a Java grammer, a "little expression
> grammar" for arithmetic expressions, and (in the LPG source) the grammar
> for LPG's .g files.
>
> Cheers,
>
> Christian
>
>
> Joel Greenyer wrote:
>
>> Christian,
>> I will have a document that has OCL statements in it, so it's the first of
>> the two cases that you described. So, technically, in some parts of the
>> grammar, I have an OCLEpression and from there on, the OCLParser should to
>> do its work.
>>
>> I'm now working myself into LPG... unfortunately the documentation is not
>> as thorough as for ANTLR.
>>
>> Well, maybe this is not so EMFT specific, but what I could use is some
>> advice on how to extend the ocl lexer/parser. Or do you know of any
>> documentation/examples available?
>>
>> Thanks
>>
>> Joel
>
> <snip>
|
|
|
| Re: best approach integrating emft ocl? [message #575501 is a reply to message #31983] |
Wed, 19 April 2006 09:09 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
Perhaps we can narrow the parameters of your question a little.
First, I should mention that ANTLR is now irrelevant; the OCL parser is
generated by LPG (the LALR Parser Generator project on SourceForge).
Do you mean that you will have text documents that mix OCL with another
language, and you want to parse the OCL bits using EMFT? That should be
fairly straightforward, as long as you can extract the OCL expressions and
feed them into either the IOCLHelper API or using the internal OCLParser
class if you want to include the context declaration syntax.
If you want to extend the OCL grammar (and, therefore, the parser) to parse
the OCL together with the rest of your text, then that is a more complex
proposition. This effectively rewrites or extends a considerable
proportion of the code in the org.eclipse.emf.ocl.internal.parser package.
The LPG project should be making documentation available that will help you
to get started with their parser generator
(http://sourceforge.net/projects/lpg).
Cheers,
Christian
Joel Greenyer wrote:
> Hi,
> This is a rather general question.
>
> If I have an application using EMFT OCL and would like to create a text
> parser for that application (that parses my stuff and OCL), what would be
> the best approach to this. I'm pretty new to EMFT and unexperienced ANTLR,
> so I seek some advice to point me in the right direction.
>
> Thanks
>
> Joel
|
|
|
| Re: best approach integrating emft ocl? [message #575533 is a reply to message #32053] |
Thu, 20 April 2006 10:26 |
| Eclipse User |
|
|
|
Christian,
I will have a document that has OCL statements in it, so it's the first of the two cases that you described.
So, technically, in some parts of the grammar, I have an OCLEpression and from there on, the OCLParser should to do its
work.
I'm now working myself into LPG... unfortunately the documentation is not as thorough as for ANTLR.
Well, maybe this is not so EMFT specific, but what I could use is some advice on how to extend the ocl lexer/parser.
Or do you know of any documentation/examples available?
Thanks
Joel
Christian W. Damus wrote:
> Hi, Joel,
>
> Perhaps we can narrow the parameters of your question a little.
>
> First, I should mention that ANTLR is now irrelevant; the OCL parser is
> generated by LPG (the LALR Parser Generator project on SourceForge).
>
> Do you mean that you will have text documents that mix OCL with another
> language, and you want to parse the OCL bits using EMFT? That should be
> fairly straightforward, as long as you can extract the OCL expressions and
> feed them into either the IOCLHelper API or using the internal OCLParser
> class if you want to include the context declaration syntax.
>
> If you want to extend the OCL grammar (and, therefore, the parser) to parse
> the OCL together with the rest of your text, then that is a more complex
> proposition. This effectively rewrites or extends a considerable
> proportion of the code in the org.eclipse.emf.ocl.internal.parser package.
> The LPG project should be making documentation available that will help you
> to get started with their parser generator
> (http://sourceforge.net/projects/lpg).
>
> Cheers,
>
> Christian
>
>
> Joel Greenyer wrote:
>
>> Hi,
>> This is a rather general question.
>>
>> If I have an application using EMFT OCL and would like to create a text
>> parser for that application (that parses my stuff and OCL), what would be
>> the best approach to this. I'm pretty new to EMFT and unexperienced ANTLR,
>> so I seek some advice to point me in the right direction.
>>
>> Thanks
>>
>> Joel
>
|
|
|
| Re: best approach integrating emft ocl? [message #575964 is a reply to message #32088] |
Fri, 21 April 2006 08:14 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Joel,
Unfortunately, the OCL lexer/parser was not designed to be extensible. I
think that you would be able to define .g files (LPG uses the same file
extension as ANTLR) that "include" rules from EMFT's OCL grammar, but I
don't know that LPG supports redefinition of rules by an extending grammar.
I think that you would have to generate a lexer and parser that either
extend the existing OCLLexer and OCLParser classes or replace them, from
some modified version of our .g files. I'm afraid that I don't know the
LPG system well enough, myself, to offer much advice ... I'm still quite
new to it.
However, if you can "call out" to the EMFT OCL parser for the OCL fragments
in your document, extending the OCL parser should only be necessary if you
need to extend the OCL language for your application. Is that the case?
The only examples that I know of for LPG (besides OCL, of course) are those
shipped with LPG, which include a Java grammer, a "little expression
grammar" for arithmetic expressions, and (in the LPG source) the grammar
for LPG's .g files.
Cheers,
Christian
Joel Greenyer wrote:
> Christian,
> I will have a document that has OCL statements in it, so it's the first of
> the two cases that you described. So, technically, in some parts of the
> grammar, I have an OCLEpression and from there on, the OCLParser should to
> do its work.
>
> I'm now working myself into LPG... unfortunately the documentation is not
> as thorough as for ANTLR.
>
> Well, maybe this is not so EMFT specific, but what I could use is some
> advice on how to extend the ocl lexer/parser. Or do you know of any
> documentation/examples available?
>
> Thanks
>
> Joel
<snip>
|
|
|
| Re: best approach integrating emft ocl? [message #575992 is a reply to message #32544] |
Fri, 21 April 2006 08:55 |
| Eclipse User |
|
|
|
Christian W. Damus wrote:
> Hi, Joel,
>
> Unfortunately, the OCL lexer/parser was not designed to be extensible. I
> think that you would be able to define .g files (LPG uses the same file
> extension as ANTLR) that "include" rules from EMFT's OCL grammar, but I
> don't know that LPG supports redefinition of rules by an extending grammar.
> I think that you would have to generate a lexer and parser that either
> extend the existing OCLLexer and OCLParser classes or replace them, from
> some modified version of our .g files. I'm afraid that I don't know the
> LPG system well enough, myself, to offer much advice ... I'm still quite
> new to it.
>
> However, if you can "call out" to the EMFT OCL parser for the OCL fragments
> in your document, extending the OCL parser should only be necessary if you
> need to extend the OCL language for your application. Is that the case?
No, I won't extend OCL itself.
I'll consider your thoughts on this. If I'll come up with a -good- solution,
I'll probably share it here.
(Maybe something like this (http://www.eclipsecon.org/2006/Sub.do?id=438) could
make life a bit easier some day.)
Thanks so far!
Joel
>
> The only examples that I know of for LPG (besides OCL, of course) are those
> shipped with LPG, which include a Java grammer, a "little expression
> grammar" for arithmetic expressions, and (in the LPG source) the grammar
> for LPG's .g files.
>
> Cheers,
>
> Christian
>
>
> Joel Greenyer wrote:
>
>> Christian,
>> I will have a document that has OCL statements in it, so it's the first of
>> the two cases that you described. So, technically, in some parts of the
>> grammar, I have an OCLEpression and from there on, the OCLParser should to
>> do its work.
>>
>> I'm now working myself into LPG... unfortunately the documentation is not
>> as thorough as for ANTLR.
>>
>> Well, maybe this is not so EMFT specific, but what I could use is some
>> advice on how to extend the ocl lexer/parser. Or do you know of any
>> documentation/examples available?
>>
>> Thanks
>>
>> Joel
>
> <snip>
|
|
|
Goto Forum:
Current Time: Tue Apr 15 05:43:22 EDT 2025
Powered by FUDForum. Page generated in 0.04073 seconds |
Home