Home » Archived » EMF-IncQuery » Compare values
| Compare values [message #1385082] |
Wed, 04 June 2014 05:04  |
Eclipse User |
|
|
|
Hi,
in a Java-Source, I want to find all occurances of a for-loop which iterates over all elements of an iterable member. Therefore I use a java metamodel ("http:\\www.emftext.org\java\" <- had to change slashes, because I'm not allowed to post links outside of eclipse.org) and load the java file as a model.
To find out, if every element of the iterable-type is used in the for-loop, I have to determine that the index variable is initialized with zero. In order to do so, I have to find an integer-litaral "0". So I tried the naive way:
DecimalIntegerLiteral.decimalValue(c,0);
which fails because of a type conflict ("The type infered from the path expression (java.math.BigInteger) is different from the input literal/computational value (int)."). So my next idea was to use the check-statement:
DecimalIntegerLiteral.decimalValue(c,r);
check(r.equals(0));
which also does not work. I get the message "Check expressions must return boolean instead of void". So I thought ok, let's try stupid things and I did this:
DecimalIntegerLiteral.decimalValue(c,r);
check({if (r.toString().equals("0")) true else false});
which didn't show any failure message but also didn't work.
Help -> About Eclipse -> Installation Details -> Plugins tells me, that I'm using version 0.7.2.201403071538.
I'd appreciate any suggestions how to solve my problem. Are there any issues known in that version concerning the check-statement?
regards,
Ronny
|
|
|
| Re: Compare values [message #1385119 is a reply to message #1385082] |
Wed, 04 June 2014 08:52  |
| Eclipse User |
|
|
|
Hi Ronny,
sadly, you have hit a known issue with the pattern language of EMF-IncQuery, as its pattern language only support a limited number of Java types outside check and eval (only available in the upcoming 0.8 version) expressions, and the referenced BigInteger type is not between them. We already have bug 398769 opened for similar reasons (https://bugs.eclipse.org/bugs/show_bug.cgi?id=398769), but as of now, we did not had the time to fix the issue.
Your second example with the check expression is close to what should be working. In that case, I guess the error message "Check expressions must return boolean instead of void" is only one of multiple error messages added to that line, as it usually relates to some internal type inference issues. Additionally, I would look at the manifest.mf of your project and see whether the org.eclipse.xtext.xbase.lib plug-in is added, as if it is missing, we have experimented very strange issues with regards to check expressions.
I hope this helps, otherwise feel free to ask for clarification.
Cheers,
Zoltán
|
|
| | | |
| Re: Compare values [message #1385173 is a reply to message #1385170] |
Wed, 04 June 2014 14:13 |
| Eclipse User |
|
|
|
Hi,
this trace shows something I have long since not seen (and not missed at all  ). When I have seen this issue, there was always some kind of strange internal behaviour of Xtext. However, I have no idea what to suggest to you.
On one hand, the upcoming 0.8.0 version should fix this issue, as we have worked a lot to make the IncQuery tooling more Xtext-conform. However, for now I know of a few quite irritating (albeit as far as I know, manageable) issues in the tooling, so I cannot recommend an upgrade full-heartedly. Of course, we plan to fix these until the release on the 2nd of July...
Cheers,
Zoltán
|
|
| | |
| Re: Compare values [message #1385192 is a reply to message #1385173] |
Wed, 04 June 2014 17:16 |
| Eclipse User |
|
|
|
Hi,
Quote:
On one hand, the upcoming 0.8.0 version should fix this issue, as we have worked a lot to make the IncQuery tooling more Xtext-conform. However, for now I know of a few quite irritating (albeit as far as I know, manageable) issues in the tooling, so I cannot recommend an upgrade full-heartedly. Of course, we plan to fix these until the release on the 2nd of July...
I think Zoli is exaggerating here. 0.8.0 is almost ready, so I recommend you give it a try (with at least Xtext 2.5.3 installed) and if possible, provide us feedback whether the problem went away.
cheers
Istvan
|
|
|
| Re: Compare values [message #1385267 is a reply to message #1385192] |
Thu, 05 June 2014 05:56 |
| Eclipse User |
|
|
|
Hi Ronny,
I think your equals-based approach will fail (regardless of IncQuery), as a BigInteger instance will never ever equal a Long or Integer.
Consequently, BigInteger.ZERO.equals(0) returns false by definition.
http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html
So even if you manage to compile your check(r.equals(0)) expression, it will always return false.
This is also the reason why the type inferrer indicates an error in your very first example, whereas DecimalIntegerLiteral.decimalValue(c,0); would be perfectly fine if decimalValue had type java.lang.Integer. But using a BigInteger-typed constant instead of the integer literal 0 would most likely work. Unfortunately, our query language does not have native BigInteger literals at the moment (in fact, it does not even have longs yet - see Bug 398769). So you have to use expression evaluation to work around the problem:
DecimalIntegerLiteral.decimalValue(c, eval(BigDecimal.ZERO));
Or if you use the constant multiple times:
zero == eval(BigDecimal.ZERO);
DecimalIntegerLiteral.decimalValue(c, zero);
SomethingElse.bigIntegerAttribute(foo, zero);
This eval() syntax should work as of v0.8.
Please tell us whether this solves your issue!
|
|
| |
| Re: Compare values [message #1385338 is a reply to message #1385335] |
Thu, 05 June 2014 13:24 |
| Eclipse User |
|
|
|
Hi,
thanks for the feedback.
1. Java is used as a keyword in the language in 0.8. To use it as an identifier, prefix it with ^, so write "^java". It is exactly the same as writing java as an identifier, just the parser needs some help.
2. I am sorry, but I am not familiar with the Ctrl+<arrow> navigation. Can you please detail what should it do and how is now behaving instead?
3. Yes, to refer the BigInteger type, you either have to import it, or use its fully qualified name. This import works similar to java classes, so java.lang.* gets imported automatically; for other cases add import java ^java.math.BigInteger to the eiq file header.
Cheers,
Zoltán
|
|
| | |
| Re: Compare values [message #1385360 is a reply to message #1385348] |
Thu, 05 June 2014 15:47 |
| Eclipse User |
|
|
|
Hi,
thanks for the suggestion. Technically you are right, the syntax is enough to distinguish between java and EPackage imports, but since 0.8 we also have a third import type for importing patterns (from other packages). Basically we made two kind of imports use optional extended keywords, while in case of java imports the additional keyword is mandatory.
So, the following kind of imports can be used
//EPackage imports
import "http://www.eclipse.org/emf/2002/Ecore"
import epackage "http://www.eclipse.org/incquery/snapshot"
//Pattern imports
import hu.bme.mit.viatra2.examples.reveng.notAbstractStateClass
import pattern hu.bme.mit.viatra2.examples.reveng.notAbstractStateClass
//Java/Xbase import
import java java.math.BigInteger
We had a detailed discussion about possible syntaxes starting in https://bugs.eclipse.org/bugs/show_bug.cgi?id=418991#c5; and relied on these settings as they seemed to be the least problematic. Again, I understand that it is hard to use sometimes; for imports we are aiming at the content assist providing the imports, thus it is not problematic to write the ^java into import declarations; for other identifiers it seemed rare enough. (And yes, the content assist is sometimes problematic in the latest release; we plan to return to the issue before the final 0.8.0 release.)
Furthermore, although this is a much more subjective stance, the importjava keyword seems a bit strange to me (and maybe for consistency we would also need the importpackage and importpattern keywords)... Maybe I could get used to it, but it does not seem natural to me. It is entirely possible that I am defending my own ideas here instead of embracing new ones; but for me that option does not seem clearly better, especially considering the amount of time until the release. Maybe others have a different opinion about it, this last part was my own subjective opinion.
However, thanks for the suggestion; it is really worth having an entirely different perspective about the costs and results of changes we make to our grammar. E.g. introducing a new keyword is kind of expensive.
Cheers,
Zoltán
|
|
| | | | | |
| Re: Compare values [message #1385435 is a reply to message #1385423] |
Fri, 06 June 2014 08:27 |
| Eclipse User |
|
|
|
Hi all,
sorry to be a party-killer here, but as I see it, we don't get closer to a consensus here. The import class alternative is by far the best one in my opinion, but even that has its share of opponents.
Seeing we have no clear alternative here, I don't think it is a good idea to change a keyword in the language after the feature-freeze milestone (it would break our promised compatability for the rest of 0. . If we would have reached a clear winner, it might have been worth it for the future, but here it is not that clear. However, if some time later we have a better idea, I am open to changing it in future releases somehow.
Thanks again for the participation and the ideas.
Cheers,
Zoltán
|
|
| | | |
Goto Forum:
Current Time: Mon Apr 28 19:35:32 EDT 2025
Powered by FUDForum. Page generated in 0.06433 seconds |
Home
Only a better error message would be handy. So thanks a lot for you nice and quick help.