Error with Annotations

Posted by Mike Fechner on 06-May-2017 02:43

Good morning,

Someone has an explanation why the compiler is unhappy with this:

IF 1 = 0 THEN
    @SomeAnnotation .
    MESSAGE "true" VIEW-AS ALERT-BOX . 
ELSE 
    @SomeAnnotation .
    MESSAGE "false" VIEW-AS ALERT-BOX . 

The error I receive on 11.6.3 is:

** Unknown Field or Variable name - @SomeAnnotation. (201)
** Could not understand line 2. (196)

If I surround the Annotation and the Message with a DO END block it works. 

Must be a bug - right?

All Replies

Posted by marian.edu on 06-May-2017 09:44

Sorry Mike, that doesn’t look like a bug to me… you’re in a middle of a statement there, allowing annotations to be present anywhere will make the language even more ambiguous so please just use an extra block if you must add annotations on then/each/case branches :)


Marian Edu

Acorn IT 
+40 740 036 212

Posted by Mike Fechner on 07-May-2017 02:12

If that would be an expected effect, then at least the error message is more than wrong.

But where exactly do you see the ambiguity? Where is the syntax to be misinterpreted? By humans or the compiler?

Von meinem iPad gesendet

Am 06.05.2017 um 16:45 schrieb marian.edu <bounce-marianedu@community.progress.com>:

<ProgressEmailLogo-png_2D00_150x42x2-png> Update from Progress Community
marian.edu

Sorry Mike, that doesn’t look like a bug to me… you’re in a middle of a statement there, allowing annotations to be present anywhere will make the language even more ambiguous so please just use an extra block if you must add annotations on then/each/case branches :)


Marian Edu

Acorn IT 
+40 740 036 212

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by marian.edu on 07-May-2017 03:20

Well, in their defence in compilers and parsers in general is not always easy to recover and come up with a meaningful error message :(


Say after ‘then’, if you don’t open a block, there can only be a single statement… no idea how they treat annotations but for the parser is probably just yet another ‘statement’, only that it probably doesn’t even expect annotation statement to be a valid single statement. Aka, annotation is not of that kind but maybe a special kind of statement that parser only expect in a block so it tries to parse that as a ‘single statement’ - trying simple assignment, execute statement, etc in one particular order and when all fails it has to give an error only there was not even a partial match there so it’s probably just using the error from last attempt.

Damn, I’m already probably using ‘probably’ too much so will probably stop here :)


Marian Edu

Acorn IT 
+40 740 036 212

Posted by Laura Stern on 07-May-2017 07:53

Marian, you were doing very well.  The error makes perfect sense to me.  Since it isn't DO, the compiler is trying to parse this as a statement.  There are only a finite set of things that can be here.  It's not a keyword, or a function or an x:y expression, etc, so it tries to resolve it as a variable/field reference.  Since an annotation is not in the syntax it can't possibly say "You can't put annotations in the middle of a statement" - I assume that's what you want it to say.

Posted by bronco on 08-May-2017 02:55

Well, Mike's code doesn't look very elegant to me (that's personal), but if you look at https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pdsoe/abl-annotations.html there's clearly states "The compiler treats annotations as comments". So that would suggest that it is indeed a bug.

Posted by marian.edu on 08-May-2017 03:16

Treats them as comments meaning 'so they do not affect how your code runs’… if you stop at first sentence having those on separate line (starts with @) it’s already a bug cause comments we can drop them anywhere :)


Laura and team can certainly fix that by allowing annotations in the parser and then do whatever required by the syntax check in the ‘lint’ part but I don’t see any need for annotations to be inserted anywhere in the code just like comments. Normally those should be ‘attached’ to something, a method/property so can be used with reflection… wonder what is Mike’s use case, why does he need to annotate a then/else decision?

Marian Edu

Acorn IT 
+40 740 036 212

Posted by Mike Fechner on 08-May-2017 03:56

Use case is to be able to annotate exception from rule validations in Gilles’ SonarLint product.
 
I really think those should be treated by a compiler as a comment that is only legal outside of a statement.

Posted by marian.edu on 08-May-2017 07:42

Ah, something like @SupressWarnings… wonder if your version of proparse is supporting this, or Gilles’ one.


Anyway, first you have to convince Laura and get the accepted by the compiler then we will worry about making it work in proparse ;)

Marian Edu

Acorn IT 
+40 740 036 212

Posted by Mike Fechner on 09-May-2017 00:12

Dealing with Proparse is a piece of cake ;-)

Will be logging this as a compiler bug then. As like Bronce said - a comment should be legal in the IF THEN ELSE without a dummy DO block.

Posted by marian.edu on 09-May-2017 00:44


That might well be treated as a documentation bug, easier to fix but I don’t want to hold you back or anything… it’s nor like I have to do it :)

For me ‘treated as a comment’ really means it doesn’t translate to anything useful, the compiler just ignores it wherever it’s found in code it doesn’t matter… while for annotations I do expect a different treatment though, it certainly won’t affect the execution (like for comments) but those should be attached to a statement and hopefully one day we can get access to those using reflection (yes, I do know those are not in r-code and you do parse them out).

Treat them literally as a comment will mean something like this should compile...

define /* is */ variable /* this */ toto /* really */ as /* usefull */ character /* ? */.

define 
@MyAnnotation is 
variable 
@MyAnnotation this 
mimi 
@MyAnnotation really
as 
@MyAnnotation usefull 
character 
@MyAnnotation ?
.


Marian Edu

Acorn IT 
+40 740 036 212

Posted by Mike Fechner on 09-May-2017 01:40

Still don't understand, why it is a bug in your eyes - just because you disagree with the coding style???

"no idea how they treat annotations but for the parser is probably just yet another ‘statement’,"

Annotations are certainly different from statements and the compiler treats them different from comments - as they can be used outside of methods and properties in a class - even outside the class block. That is not a bug - that is a feature.

Any yes - the fact that they cannot be used inside a "regular" statement makes them different from comments as well - also the fact that they have their own syntax rules between the opening @ and the closing period..

Posted by marian.edu on 09-May-2017 02:28

Who, me? I haven’t say I disagree with anything, I also accept others like to use ALL CAPS keywords so pretty easy going on that subject… I don’t see it as a bug because it doesn’t bothers me ;)


Was just trying to point out that the ‘fix’ should not be to let annotations everywhere in the code as is the case with comments… where exactly those should be allowed is a thing Laura’s team will decide.

Back to your original code, since Progress implementation looks more like Java annotations (not .net attributes) what you want to have implemented doesn’t work in Java either although the error message is more appropriate (type annotations are illegal here). Even typed annotations added in Java 8 can’t be used everywhere like comments, before those were valid only for declarations (class/method/property), type annotations can now be used whenever a ‘type’ is used - new, cast, implements and throw. But that’s it, we can’t just use them in the middle of a if/then/else statement… however, this is not saying Progress can’t implement that if they see fit.

Marian Edu

Acorn IT 
+40 740 036 212

This thread is closed