Zugg Software :: View topic - Problems with the

Posted: Tue Apr 18, 2006 1:29 am

I've run into another case of ambiguous syntax in zMUD that needs to be fixed in CMUD. Now that CMUD is performing math evaluation as the default, take a look at the following code:

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

My call would be to require {A|B|C} {1|2|3} syntax regardless of string or integer members. It makes a lot more sense in the {x|y|z} represents a collection.

Posted: Tue Apr 18, 2006 4:02 am

Well yes, as I said that's not really the point. {A|B|C} and {1|2|3} already work just fine. I'm talking about the case where the {} are left out as in the example that I showed.

Sure, I could just flag this as a syntax error and refuse to execute it (or execute it as the mathematical OR operation that they didn't intend). But my job here is to try and maintain as much compatibility with zMUD as possible. The more things I change in CMUD, the fewer people who will upgrade. I want *everyone* to upgrade. I don't want to have to support zMUD in 2 years.

Lot's of people use string lists. Lot's of people leave out the quotes or {} around them. And *NOBODY* ever uses 1|2|3 on purpose to represent a mathematical OR operation in zMUD. The only time this syntax is used is in logical expressions within parenthesis, like this:

#IF (@a|@b) {true} {false}

SO wouldn't it make more sense for CMUD to treat @a|@b (without parenthesis) as a string list, and only perform the logical OR when you have (@a|@b) (with parenthesis)? That's certainly what most people would expect, and I want CMUD to work the way that most people would expect.

Enchanter Joined: 10 Oct 2000 Posts: 698

I realize this isn't what you had in mind, but I think both things should be done.

1. Referencing/assigning/manipulating lists should be require the use of braces, period. Let the syntax error flag fly proudly.
2. || should be changed the default logical OR operator syntax. This is not a common enough construct to give casual scripters problems in my opinion.

Although I hadn't thus far weighed in on the 'do it right' debate, I am on the 'fix it all' bandwagon. With that, I'm going to start a new topic, I think.

Wanderer Joined: 30 Dec 2001 Posts: 66 Location: USA

It would make sense to me if a=1|2|3 or a={1|2|3} should default to a mathmatical operation. Then require that "" as in a={"1|2|3"} or a="1|2|3" be flagged as a string list.

Just my two cents.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

when I'm thinking an 'or' operator, I think of a double pipe (||) instead of a single pipe. Might this just be a change that cmud makes? after all, double pipe is the more common use in other languages and lessens the learning curve.

Posted: Tue Apr 18, 2006 7:14 am

What I had in CMUD already was using a || for the logical OR operator, but a single | for a bitwise OR operator. I think this is what C does (or maybe I'm not remembering correctly). But perhaps we don't need the bitwise OR operator and can stick with ||. That would certainly solve most of the problem, except for people who are silly enough to have something like this in their script:

List=a||b

where they are trying to create a 3-element list with a null as the second element. People who do this probably deserve to get a syntax error Wink

Also, when I get around to writing some sort of script conversion utility, it would be pretty straightforward to replace | in IF statements with || instead. So I think I'll go with the || change for now instead of trying to force a kludge.

Posted: Tue Apr 18, 2006 7:18 am

tomcat025: Using " quotes doesn't work because it's common to use variables to create a string list and variables are not expanded within quotes. If you have read the other posts in this forum you'll note that in CMUD, {} is really just a variation of the " double-quotes. {} acts like quotes except allows variable expansion. "" is for literal strings with no variable expansion. So doing something like {"1|2|3"} is really redundant and doesn't make any sense for CMUD.

So, because {} is already a string operator, both "1|2|3" and {1|2|3} are already handled as string lists, and this won't change. To force a mathematical expression, you use parenthesis in CMUD. So (1|2|3) will always be a mathematical expression (...well, unless I change | to || like we have talked about).

Anyway, just wanted to point this out to try and drill home the concept of what {} are used for in CMUD.

Wanderer Joined: 30 Dec 2001 Posts: 66 Location: USA

Thank you for the clarification Zugg. It has been so long since I read the help files. To tell the truth, I was half asleep when I posted that.

I am a bit confused however. Please correct me if I am wrong here.

| is going to be used for string lists and || as an OR operator for mathmatical function?

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Zugg, I dug out my copy of TurboC++ and copied the help file for single pipe operator:

Posted: Tue Apr 18, 2006 7:24 pm

Slicertool, thanks for the post...it was good to refresh my memory. And I think I'm more convinced that we should stick with function calls for bitwise operations (like %bitor, %bitand, etc which already exist) and not try to use | or & for these.

Also, just to be complete, if I change the logical OR operator from | to || then I will also change the logical AND operator from & to &&. Might as well be consistent.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Good call. Keep bitwise as functions, certainly if zMUD didn't support them.

Also if people have #VARTYPE'd list as stringlist then any @list = {a||c} operation could be detected and have the 3 elements showing up as 'a' '' and 'c'

Posted: Wed Apr 19, 2006 12:07 am

Yep Rainchild, that's exactly right. And I've already added some stuff to CMUD in the "auto type" detection for string lists. So when you do something like this:

list={a||c}

CMUD will actually detect that this is a string list and change the type automatically to StringList (assuming @List had a type of Auto to begin with). So you don't even need to Vartype-it in the first place.

I should mention that I was still able to add a bit of compatibility that will help existing zMUD users. If you look at the F1 help for #IF or #WHILE or anything else that takes a boolean expression you will notice that the argument type is "Boolean" rather than just the normal "Expression". So in CMUD I have added a check and if it sees | or & within a Boolean argument, then you get the OR and AND operation, rather than the string list operation.

This restores probably 90% of the compatibility while having a nearly zero impact on string lists.

In other words, when there is an ambiguity with |, if it is parsing a Boolean argument the OR operation has precedence, whereas the STRINGLIST operation has precedence everywhere else. There is only ambiguity when no delimeters are used. If you use {} then it will always be recognized as a string list no matter what argument it's used in.