Home » Archived » EMF-IncQuery » Warning about cartesian product seems unnecessary in some cases
| Warning about cartesian product seems unnecessary in some cases [message #1006202] |
Wed, 30 January 2013 07:46  |
Eclipse User |
|
|
|
I really love the great feedback that the IncQuery editor is giving me on developing the pattern queries.
However, I just used the following pattern (Literal is the superclass of IntegerLiteral, BoolLiteral and has no other subclasses):
pattern literalType(literal : Literal, type) ={
IntegerLiteral(literal);
type == "integer";
} or {
BoolLiteral(literal);
type == "bool";
}
And this will warn me of a Cartesian product as the literal and type constraints are isolated. As I want to propagate the type through the expressions (e.g. comparing two ints yields a bool, adding/subtracting two ints yields something of type int again), I would like to annotate the tree with such kind of information. Although the Cartesian product warning is correct, it is a Cartesian product of a list combined with exactly one value (a type string literal).
Am I missing a crucial point here? Is there actually a potential memory or performance problem here?
About my actual intended goal: I'd like to make an equivalent of an expression walker with these patterns to validate (and hopefully transform) the expressions used in my DSL.
Perhaps I need to use some derived feature for this, (like in the derivedFeatures example) but I do not have the experience to tell if this is going to be a good call if I would also be using IncQuery for validations and transformations.
|
|
| | |
| Re: Warning about cartesian product seems unnecessary in some cases [message #1006245 is a reply to message #1006202] |
Wed, 30 January 2013 09:55  |
| Eclipse User |
|
|
|
Joost, please disregard what István just said.
Joost van Pinxten wrote on Wed, 30 January 2013 07:46
lthough the Cartesian product warning is correct, it is a Cartesian product of a list combined with exactly one value (a type string literal).
Am I missing a crucial point here? Is there actually a potential memory or performance problem here?
No, you are completely right, there is no performance issue here. We just did not think of this case, and neglected to add a specific exemption from the Cartesian rule of the validator for the case of constant literals. This is a TODO for us in the future: https://bugs.eclipse.org/bugs/show_bug.cgi?id=399497
In the meantime, you can happily ignore the warning and use your pattern.
Joost van Pinxten wrote on Wed, 30 January 2013 07:46
Perhaps I need to use some derived feature for this, (like in the derivedFeatures example) but I do not have the experience to tell if this is going to be a good call
Essentially, if you would like to access the set of inferred types from plain Java code as conveniently as myExpression.getInferredTypes(), then you need to create a (query-based) derived feature for it, using the exact same patterns. If you do not need this added convenience, you can use the IncQuery matcher API with the patterns you are defining here, and then there is no need to fiddle around with injecting derived features into the metamodel.
However, if you wish to calculate some of these types by a complicated algorithm that you express in Java only, then (non-query based) derived features are the clear choice.
Istvan Rath wrote on Wed, 30 January 2013 08:39Hi,
the first thing I'd recommend is to stick to the general best practice of always explicitly specifying types for your header variables.
Don't do that! Generally good advice, but not in this case. EString and java.lang.String are not the same (you can think of EString as something like subtype), and "bool" is a String, but not an EString (unless it also appears as an EString attribute of some EObject), so adding EString as a type constraint may discard your matches.
Istvan Rath wrote on Wed, 30 January 2013 08:39
Yes! This pattern will instruct IncQuery to track all EString instances in your model
No, it won't. We are actually a bit more clever than that.
|
|
|
| Re: Warning about cartesian product seems unnecessary in some cases [message #1006314 is a reply to message #1006245] |
Wed, 30 January 2013 14:19 |
| Eclipse User |
|
|
|
Quote:Joost, please disregard what István just said.
I reckon Gabor's (somewhat rude, but you be the judge) statement refers to my first (and truly incorrect) answer.
Quote:
Quote:the first thing I'd recommend is to stick to the general best practice of always explicitly specifying types for your header variables.
Don't do that! Generally good advice, but not in this case. EString and java.lang.String are not the same (you can think of EString as something like subtype), and "bool" is a String, but not an EString (unless it also appears as an EString attribute of some EObject), so adding EString as a type constraint may discard your matches.
Which, in my view, means that this pattern is at least a borderline case between what can be considered good practice and something to avoid (unless absolutely necessary). Especially considering the fact that the type inferencer reports EString as the inferred EMF type of the variable in question.
In summary I think that "scalar" (i.e. non model element) variables that are not coming from a model attribute value is an area of the IncQuery Pattern Language that we need to work on a bit more. And in the mean time, users should take extra care while using them.
|
|
| | | |
| Re: Warning about cartesian product seems unnecessary in some cases [message #1008305 is a reply to message #1008248] |
Mon, 11 February 2013 15:24 |
| Eclipse User |
|
|
|
Thanks for the heads up Abel. However, since I've deduced the behavior that I described from experiments, I thought I'd recheck. So I've just run this through the interpreter (Query Browser that is):
Example 1, with string literals
pattern literalType(literal : Literal, type ) = {
IntegerLiteral(literal);
type == "integer";
} or {
BoolLiteral(literal);
type == "boolean";
} or {
StringLiteral(literal);
type == "string";
} or {
IntegerArrayLiteral(literal);
type == "integerArray";
}
Example 2, with EMF enum literals
pattern literalType2(literal : Literal, type : Type ) = {
IntegerLiteral(literal);
type == Type::integer;
} or {
BoolLiteral(literal);
type == Type::bool;
} or {
StringLiteral(literal);
type == Type::string;
} or {
IntegerArrayLiteral(literal);
type == Type::integerArray;
}
Example 2 does NOT return me any matches, while example 1 returns 15 (obviously on the same EMF instance model).
This should be considered a bug then? Or am I missing the point here?  FYI, the Type enum is also never referenced from an attribute, it is solely used to propagate types up the expression tree through the patterns used above.
|
|
| | | |
Goto Forum:
Current Time: Tue May 13 01:44:19 EDT 2025
Powered by FUDForum. Page generated in 0.10449 seconds |
Home
. Perhaps this discussion has enough information, but maybe a use case where some kind of grammar is checked by employing this kind of pattern would be a nice addition to the tutorials?