Compile and run the following: the MSG should not be put up, but it is put up. The precompiler incorrectly moves the statement following the END ELSE to the next line.

SUBROUTINE TEST

IF 1 THEN

 NULL                                            

END ELSE NULL; CALL MSG("This should not display")

RETURN

Hmph.

I can't believe the arev compiler would allow this to compile.

I'm still bothered that we haven't forced the compiler to generate errors when reserved keywords are used as variable names- e.g. ABORT, LEN, etc. It would break to many programs I fear, which is why we haven't done it.

We'll look at both the precompiler and compiler at this.

Thanks-

Mike

The ARev compiler lets you use the same word as label and variable too. e.g.:

process: process=1

or

declare function process

process: process=process()

BTW, technically if you have end else AND a statement on a line, only a single statement is allowed after the else. So, AREV is the one incorrectly compiling the original code. Everything after the ";" on that line is outside the if..then..else statement and will execute all the time. The only way it _should_ allow two or more statements to execute (in this case null and msg()) is to drop them to a lower line and include an END to the if..then clause.

Trying to get tricky with if..then..else all one line can run you into a lot of trouble. Simple stmts work fine that way, but very complex ones can be a little unpredictable in where the compiler will decide the clauses belong.

Yeah- ain't it grand?

Back when I used to write compilers in school these were some of the basic items to disallow. Sure you have tremendous flexibility, but man, it can go pear shaped real fast.

Karen,

Yes, it was hasty of me to imply AREV32 is "wrong."

Here, right or wrong is compared to what it is "supposed" to do. In this case, I think AREV32 is "supposed" to do the same thing AREV does, and AREV includes additonal statements after the ELSE as being part of the ELSE clause. From an arbitrary logic point of view, I could see either way making sense. Not having programmed in other PICK flavors, I have no other point of reference.

Of course, if AREV32 does something other than what AREV does, then that's a problem because pre-existing code will change its behavior.

But, OI also does what AREV does, so if AREV is "wrong," so is OI.

Regardless, I will admit that it's bad form, whether the compiler allows it or not. To me, the biggest problem is there's no way to look at it and a priori be certain what it will do.

BTW, all 3 (AREV, AREV32, and OI) will execute the statements following the ELSE as part of the ELSE clause here:

if TRUE then DoThis else DoThat; DoTheOtherThing

That is, DoTheOtherThing only gets done if not(TRUE). I think the first time I ran across this was when using the old ARev batch update, which only allowed one line of code. I seem to remember, come to think of it, being truly annoyed that the statement after the semicolon was not treated as a new line.

I'm having the same problem, we have a routine called, believe it or not, PRINTER. AREV32 won't compile routines that call this subroutine.

Bad coding on our behalf.

]

No doubt it is supposed to. But just as all the old AREV code was lost, then re-written with some slight differences, OI/AREV32 is all new – so bugs never caught will be (this is one) and new ones introduced (see most other messages about AREV32 so far). At one point, long ago, I know AREV did it right (as I have been careful to NEVER do this for the last (too many to count) years, having been bitten long ago).

]

Now, that is funny. Perhaps it makes up for all the places OI does things differently. Although it will take more than this to compensate for the insane decision to store only the oconv() value in a form, rather than true iconv() values (or both, if NOTES really needed the display format), requiring both lots of code and extra controls to get around it, plus many more conversions that are completely unnecessary. True, computer cycles do keep getting faster and cheaper, but adding a few hundred extras for no reason is foolish (although no doubt in the tradition of M$ to increase hardware requirements with every release), not to mention exceedingly annoying for the programmer.

It's one of the things that can bite you if using EVAL in TCL in AREV, as well. The stuff after the ";" should not be part of the else, but AREV incorrectly (and all the others, it seems) jams them together.

Having written a compiler or two, long ago, I can be a pain to find all the odd cases, especially in a very rich and flexible language. Much easier to just document the "features".

Any status on this issue (inclusion of clauses following ELSE)?

Thanks,

David

Hi, David. Sorry I hadn't posted this sooner.

I've modified the precompiler to properly support the AREV syntax. It should now operate as you'd expect (right or wrong)

Thanks,

- Bryan Shumsky

Revelation Software

View this thread on the Works forum...