Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I know yes, no, on, off, true, and false are considered reserved words for expression. I am having a problem with a particular expression that is part of a script. The portion of the script that I traced it to is "#IF (@DirQueue) {". Probably this is the only script that will have this problem, but some how "n" became a reserved word for false

#IF ("n") {#SHOW Yes} {#SHOW No}
Now displays No. It should be displaying yes.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I did some further testing with this, and it looks like on and off got remove from the reserved which is good.

The bad news is that is that f works as short for false. Also the reserved words work in a few variations where we wouldn't want them to.
#IF (%concat("n","o")) {#SHOW Yes} {#SHOW No}
#IF ("f") {#SHOW Yes} {#SHOW No}
#IF ("no") {#SHOW Yes} {#SHOW No}
#IF (%char(70)) {#SHOW Yes} {#SHOW No}

So a simple fix really won't work here, those words shouldn't even work when in quotes, contained by a variable, or assembled through insane manipulations. This is a parsing problem that might have to be put off, but it would be good to fix the single letters so they are right for now.

Posted: Sun Oct 28, 2007 6:57 am

Confirmed. Vijilante I've got to admire your bug hunting skills. I know you know the product almost as well as Zugg but half of these issues I couldn't even imagine until you do them.

Posted: Mon Oct 29, 2007 10:10 pm

Excellent testing!

Should Yes/No even be allowed as reserved words anymore?

The bug applies to True/False also, however, and I agree that this needs to be fixed.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

It occurs to me that this is more an order-of-operations bug than a problem with the list of reserved words. In other words, the bug is that the check for reserved words is happening AFTER the evaluation of the condition in the %if statement, and it should only happen BEFORE the evaluation of the condition (during parsing, for instance). If that were the case, all the concats and other manipulations wouldn't cause any problems (even if you assembled the word "false"), because the check for reserved words wouldn't get called at that point.

Or is there some reason I'm missing for the re-parsing step?

That said, I agree that 'n' and 'f', etc. should NOT be reserved words. And I wouldn't mind seeing 'yes' and 'no' go either. If you want the syntactic candy, throw in built-in %yes and %no, or whatever.

Wizard Joined: 14 Aug 2004 Posts: 1269

I won't miss 'yes' and 'no'. If True and False are too long to type, one can just use 1 and 0. I would not have expected any abbreviations for them to be possible.

Posted: Tue Oct 30, 2007 1:44 am

No, actually the problem *is* happening in the parser. When checking for True/False it is actually allowing the values within a string instead of just within an expression. This is somewhat left over from zMUD since zMUD didn't have any distinction between a string with or without the quotes. It's just one of those "weirdnesses" left over from zMUD that didn't get fixed.

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

For once I think this should be like other compilers. True/False should be reserved, and of course any non-zero value should return a TRUE.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I agree only TRUE and FALSE should be reserved. I could even live without them, in fact I can't recall ever using them. I also can't recall anyone ever mentioning them unless it was a Guru explaining why a script wasn't working.

Enchanter Joined: 10 Oct 2000 Posts: 698

Heh! I use TRUE and False in some of my zMud scripts but it's easy enough to get around their use. Stay or go - makes no difference. From a practical standpoint, I just want my scripts to work and my triggers to match. The reserved word stuff is mostly just extra fluff and another chance for introducing errors IMHO.

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Being reserved doesn't just imply it is used like a command, especially when you are considering true and false. They are reserved due to their use in boolean variables. Using zero and non-zero for true and false, as far as I know, doesn't change the interpretation as FALSE/TRUE.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

Posted: Wed Oct 31, 2007 7:45 pm

Yeah, this bug was nasty. In CMUD, results are returned as special class objects that can contain different value types (sort of like Variants). This is my own class that I have been using for a long time. One of the class properties is "AsBoolean" which returns the result as a true/false value. Obviously if there is a number stored, then it returns false if zero, and true if non-zero. But when there is a string value stored, I discovered that it is actually checking for "false", "f", "no", "n", "true", "t", "yes", "y" strings and handling them specially.

So, it wasn't a parser issue after all. jquilici was correct that it was happening post-parser by the routine that was checking the result.

Dealing with 0/1 is also a bit tricky when dealing with AutoType values. I've modified it so that putting a 0 or 1 within a literal string like "0" and "1" will always be true (non-null strings). Otherwise, if it's not a literal string, but the result of a function expansion, like %concat("0"), then it will actually return false in that special case. This is because the result of a function is AutoTyped, so the "0" string value gets converted to a 0 numeric value, which returns false. Hope that makes sense.