Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Tue Apr 18, 2006 1:29 am   

Problems with the | operator
 
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:
Code:
a=1|2|3

So, is this supposed to be a string list or a mathematical OR operation?

With the math evaluation as the default in CMUD, the above code is currently parsed as a mathematical OR operation (with a result of 1). But string lists are more common in zMUD than using the OR operation. So the result that you probably prefer is to return the 1|2|3 string list.

Of course you can put {} or "" around it to remove this ambiguity, but that's not what this post is about. I still have to deal with making the default make sense.

The case of
Code:
a=Zugg|Chiara

is easier to handle since it's obvious that a mathematical OR operation doesn't make sense here.

So, should I just require {} around numeric string lists? Or should I do something different?

Should I change the | OR operator in CMUD to be || to better match C/C++? If so, how many people are using | instead of the OR keyword in their IF statements?
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Tue Apr 18, 2006 2:57 am   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Tue Apr 18, 2006 4:37 am   
 
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.
Reply with quote
tomcat025
Wanderer


Joined: 30 Dec 2001
Posts: 66
Location: USA

PostPosted: Tue Apr 18, 2006 6:56 am   
 
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.
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Tue Apr 18, 2006 7:05 am   
 
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.
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
tomcat025
Wanderer


Joined: 30 Dec 2001
Posts: 66
Location: USA

PostPosted: Tue Apr 18, 2006 9:38 am   
 
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?
_________________
You can pick your nose. You can pick your friends... but you can't pick your friends nose.

~Arwin Hochhauser
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Tue Apr 18, 2006 4:39 pm   
 
Zugg, I dug out my copy of TurboC++ and copied the help file for single pipe operator:

Code:
 
  Logical and bitwise operators    & ^ | && ||
 
Turbo C++ offers these bitwise and logical
operators:

 &   bitwise AND
 ^   bitwise exclusive OR
 |   bitwise inclusive OR

 &&  logical AND
 ||  logical OR

Syntax:
 AND-expression    &  equality-expression
 exclusive-OR-expr ^  AND-expression
 inclusive-OR-expr |  exclusive-OR-expression
 logical-AND-expr  && inclusive-OR-expression
 logical-OR-expr   || logical-AND-expression

In these expressions, both operands must be of
integral type:

 E1 & E2     E1 ^ E2     E1 | E2

In these expressions, both operands must be of
scalar type.

 E1 && E2    E1 || E2

The usual arithmetical conversions are
performed on E1 and E2.

For the bitwise operators, each bit in the
result is:

    Bit value            Results of
                
  in E1 in E2 E1 & E2 E1 ^ E2 E1 | E2
 
    0      0       0        0        0
    1      0       0        1        1
    0      1       0        1        1
    1      1       1        0        1

Unlike the bitwise operators, && and ||
guarantee left-to-right evaluation.

E1 is evaluated first; if E1 is zero, E1 && E2
gives 0 (false), and E2 is not evaluated.

With E1 || E2, if E1 is nonzero, E1 || E2
gives 1 (true), and E2 is not evaluated.
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Tue Apr 18, 2006 11:19 pm   
 
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'
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net