Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » questions about JvmModelInferrer
questions about JvmModelInferrer [message #853056] Sun, 22 April 2012 12:55 Go to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1321
Registered: July 2009
Senior Member
Hi

I have a DSL (http://xsemantics.sourceforge.net/ ) which allows writing
kinds of rule systems, and the rules rely on Xbase (plus some custom
additional expressions). I already have the generator working for this
language (even for xtext 2.3M), but the generator is written "manually",
i.e., with xtend2, without relying to the JvmModelInferrer at all (of
course I also have custom xbase scope provider and compiler). And
everything works.

However, I'd like to port the generation to JvmModelInferrer mechanism,
but I don't know whether it is feasible... I'll try to sketch the
problems I'm facing when trying to switching to the inferrer... (I'm
using Xtext 2.3M since from what I understand it has new features
concerning the inferrer mechanisms, and some bugs fixed)

The rules of the systems you can write with my DSL are of this shape
(simplified)

system MySystem {

imports...

rule MyRule
JavaType1 p1, JavaType2 o1, ...
{
<Xbase expressions plus custom syntax>
}

....other rules
}

where "JavaTypei xx"'s are FullJvmFormalParameters

for the system a Java class is generated and for each rule I generate
some methods into the Java class...

the problem I'm facing with the inferrer is that some of the
FullJvmFormalParameters of the rule must correspond to the generated
method's parameters (e.g., the p1 above), while others are output
parameters (e.g., the o1 above) thus they correspond to local variables
in the generated method. Furthermore, the type of the generated Java
method does not correspond to the Xbase expression block's last
expression; for instance the generated Java code is something like

public Result<SomeType> MyRuleGenMethod(final JavaType1 p1) {
JavaType o1 = null; // corresponds to the original
// rule's output parameter

...Java code generated through custom xbase compiler ...

return new Result<SomeType>(
...Java code generated through custom xbase compiler
... using the local variables corresponding
... to the output params
)
}

as I said, at the moment, I have everything working WITHOUT the
JvmModelInferrer

now, if I want to use the inferrer and I use JvmTypesBuilder.toMethod in
the inferrer, the xbase validator will complain about missing references
for the output parameters (since they are not in the signature of the
method) and about the return type (which does not correspond to the one
of the last xbase expression)... even though I have a custom compilation
of the method body

rule.toMethod(
'''applyRule«rule.toJavaClassName»'''.toString,
rule.resultType
)
[
parameters += rule.inputParameters

body = [
rule.declareVariablesForOutputParams(it)
rule.compileRuleBody(rule.resultType, it)
]
]

where compileRuleBody uses the custom xbase compiler for generating the
body of the rule and finally generates the Java code for returning the
result...

My question is: is it correct to use the JvmModelInferrer in this
situation? Or is it better to have a minimal JvmModelInferrer (e.g.,
only for the Java class of the main system) and then possibly have a
custom JvmModelGenerator which generates Java code by using for instance
JvmTypesBuilder.toMethod (I guess during the generation the xbase
validator will not complain anymore, will it?).

Or should I stay with the current working manual generation? :)

sorry for the long email
and thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
Re: questions about JvmModelInferrer [message #870043 is a reply to message #853056] Sat, 05 May 2012 18:44 Go to previous message
Jan Koehnlein is currently offline Jan Koehnlein
Messages: 656
Registered: July 2009
Senior Member
I'll try to give a short answer: The main difference between using a
Java generator and using a JVM model inferrer (and the JvmModelGenrator
to create Java) is that in the latter case we can keep a trace to the
original source elements, which is used in the tooling (navigation,
search, refactoring, debugging etc.) It is completely OK to provide your
own non-inferred or non-associated JVM model elements as long as you
don't need the tooling for these elements. In this case there is no need
to constrain yourself to the capabilities of the JvmTypesBuilder.
E.g., unmapped parameters should not be a big issue.

Am 22.04.12 18:55, schrieb Lorenzo Bettini:
> Hi
>
> I have a DSL (http://xsemantics.sourceforge.net/ ) which allows writing
> kinds of rule systems, and the rules rely on Xbase (plus some custom
> additional expressions). I already have the generator working for this
> language (even for xtext 2.3M), but the generator is written "manually",
> i.e., with xtend2, without relying to the JvmModelInferrer at all (of
> course I also have custom xbase scope provider and compiler). And
> everything works.
>
> However, I'd like to port the generation to JvmModelInferrer mechanism,
> but I don't know whether it is feasible... I'll try to sketch the
> problems I'm facing when trying to switching to the inferrer... (I'm
> using Xtext 2.3M since from what I understand it has new features
> concerning the inferrer mechanisms, and some bugs fixed)
>
> The rules of the systems you can write with my DSL are of this shape
> (simplified)
>
> system MySystem {
>
> imports...
>
> rule MyRule
> JavaType1 p1, JavaType2 o1, ...
> {
> <Xbase expressions plus custom syntax>
> }
>
> ...other rules
> }
>
> where "JavaTypei xx"'s are FullJvmFormalParameters
>
> for the system a Java class is generated and for each rule I generate
> some methods into the Java class...
>
> the problem I'm facing with the inferrer is that some of the
> FullJvmFormalParameters of the rule must correspond to the generated
> method's parameters (e.g., the p1 above), while others are output
> parameters (e.g., the o1 above) thus they correspond to local variables
> in the generated method. Furthermore, the type of the generated Java
> method does not correspond to the Xbase expression block's last
> expression; for instance the generated Java code is something like
>
> public Result<SomeType> MyRuleGenMethod(final JavaType1 p1) {
> JavaType o1 = null; // corresponds to the original
> // rule's output parameter
>
> ...Java code generated through custom xbase compiler ...
>
> return new Result<SomeType>(
> ...Java code generated through custom xbase compiler
> ... using the local variables corresponding
> ... to the output params
> )
> }
>
> as I said, at the moment, I have everything working WITHOUT the
> JvmModelInferrer
>
> now, if I want to use the inferrer and I use JvmTypesBuilder.toMethod in
> the inferrer, the xbase validator will complain about missing references
> for the output parameters (since they are not in the signature of the
> method) and about the return type (which does not correspond to the one
> of the last xbase expression)... even though I have a custom compilation
> of the method body
>
> rule.toMethod(
> '''applyRule«rule.toJavaClassName»'''.toString,
> rule.resultType
> )
> [
> parameters += rule.inputParameters
>
> body = [
> rule.declareVariablesForOutputParams(it)
> rule.compileRuleBody(rule.resultType, it)
> ]
> ]
>
> where compileRuleBody uses the custom xbase compiler for generating the
> body of the rule and finally generates the Java code for returning the
> result...
>
> My question is: is it correct to use the JvmModelInferrer in this
> situation? Or is it better to have a minimal JvmModelInferrer (e.g.,
> only for the Java class of the main system) and then possibly have a
> custom JvmModelGenerator which generates Java code by using for instance
> JvmTypesBuilder.toMethod (I guess during the generation the xbase
> validator will not complain anymore, will it?).
>
> Or should I stay with the current working manual generation? :)
>
> sorry for the long email
> and thanks in advance
> Lorenzo
>


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Previous Topic:Restricting Xbase in my own grammar
Next Topic:some newbie questions...
Goto Forum:
  


Current Time: Thu Aug 21 00:41:02 EDT 2014

Powered by FUDForum. Page generated in 0.02348 seconds