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: 23379
Location: Colorado, USA

PostPosted: Wed Mar 29, 2006 6:36 pm   

Expansion vs Evaluation in CMUD
 
I'd like to get some discussion on an issue that has plagued zMUD for a long time.

In zMUD, there are three commands for assigning a value to a variable:

#VAR name value
#MATH name value
#FUNC name value

the only difference between these commands is how "value" is stored. For the #VAR command, "value" is *expanded*. This means that any variable or function references are expanded. For the #MATH command, the "value" is *evaluated*. This means that any mathematical expressions are evaluated. For the #FUNC command, "value" is left untouched.

Examples:

a = 2
#VAR varname @a+1
-> stores "2+1" into varname
#MATH varname @a+1
-> stores "3" into varname
#FUNC varname @a+1
-> stores "@a+1" into varname

The short syntax of "name = value" is the same as using the #VAR command, so doing

varname = @a+1
-> stores "2+1" into varname

OK, those are the rules used in zMUD. They are consistent and have been used for a long long time. It's impossible to change this in zMUD without breaking some wierd compatibility.

But we all know that this is just wierd behavior. When someone assigns:

varname = @a+1

they expect @varname to have a value of "3" and not "2+1". This makes zMUD work differently than any other programming language and can be very frustrating for new users.

So my question is: do we really need to keep doing this? In CMUD can I change it so that #VAR and var=value perform *evaluation* instead of just *expansion*.

My proposal is to change #VAR assignment so that it works like the #MATH command. A new command (probably called #EXPAND or something like that) could be used to replicate the old #VAR behavior if needed.

Would this change cause any big problems? If so, I'd like to see some simple script examples showing how the current zMUD #VAR behavior is an advantage over the more expected MATH behavior.

The other nice side effect would be that you could get rid of a lot of unnecessary %eval calls or usage of the [] for immediate evaluation. It would really simplify the CMUD scripting and make it work more as expected for most people.

Please comment.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Mar 29, 2006 9:29 pm   
 
Sounds reasonable to me - 90% of my #VAR statements use the %eval( ) syntax. The other 10% are initializers - eg #VAR xp_gained 0.

Just as long as something like:

a = "foo"
b = "bar"
#VAR varname @a+" "+@b

would store "foo bar" rather than try and perform math on it...
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Mar 29, 2006 10:15 pm   
 
It sounds like a great working plan to me. And it will certainly be a boon to new users.

It will also make scripts easier to debug.
_________________
Asati di tempari!
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 12:27 am   
 
Yep, the + operator acts as a Concat function if either of the arguments are a string.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Thu Mar 30, 2006 1:05 am   
 
Will it have any effect on zMUD script imports?

If not then I say yes to the change, it'll be much nicer to have it behave like other scripting languages.
_________________
Taz :)
Reply with quote
hav
Wanderer


Joined: 05 Oct 2004
Posts: 61
Location: Riga, Latvia

PostPosted: Thu Mar 30, 2006 2:57 am   
 
Yes, + being both math function and concat, as well as the whole #VAR %eval() mess is in fact bloody confusing.
Why bother cramming both under same char, + fits summing intuitively but how about using something different for concat, for example ||
Thus #VAR varname @a+1 would be 3 and #VAR varname @a||1 would be 21
I am guessing this might also spare cmud some processing time as it now doesnt have to waste resources guessing in what way to use + depending on @a contents.
Either that, or go with the typical programming language approach. Give variables datatypes, boolean, string, integer, longint and so forth, add conversion functions between types, and so on. But I dont like how it sounds, would be too confusing for a casual mudder.
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 4:05 am   
 
No, || is already used in zMUD and other languages for the OR operator.

+ is used for Concat in Delphi (Pascal), so it's already a standard. VBScript uses & but that is already a special character in zMUD. Also, existing zMUD scripts already use + for concat, so changing this would break a lot of scripts.

There is no problem with + being used for both plus and concat as far as parsing. It doesn't cause any slowdowns or confusion in the parser.

Also, zMUD and CMUD will always be "typeless" languages. Again, that kind of change would completely break existing scripts.

Compatibility with zMUD is still very important in CMUD, so I'm not going to completely revamp the entire language. People are still free to use VBScript or JScript or any other scripting language they are more familiar with.

The point of this thread is that the existing expansion vs evaluation behavior is not only very confusing and non-standard, but changing it shouldn't have very much impact on existing scripts since anyone counting upon the current expansion behavior should be very rare. And performing an extra %eval in existing scripts doesn't hurt anything if the eval is already done automatically.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu Mar 30, 2006 10:51 am   
 
I am definitely all for this change. I remember when I first started using zMud it took me a while to figure out why assignments didn't do math the way every other language did. So this change should be beneficial to everyone.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
hav
Wanderer


Joined: 05 Oct 2004
Posts: 61
Location: Riga, Latvia

PostPosted: Thu Mar 30, 2006 1:03 pm   
 
No, still not convinced. Switching defaulting from concat to sum is certainly improvement for me, my scripts use sum more often than concat, just that now the mess is reversed when + is actually is used for concat, #VAR %nosumplease() or whatever the function would be called.
I only used || for example, could be anything, and even defined on Special Characters tab. Likewise, + behaviour if its used for concat could also be toggled in settings, keeping enabled by default for backwards compatibility with zmud scripts. I see no harm done if zmud is more customizable to perform the way user wants.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Thu Mar 30, 2006 3:58 pm   
 
hav wrote:
#VAR %nosumplease() or whatever the function would be called.

It would be called #VAR %concat() and it already exists.

Having %eval implied for numbers and %concat implied for strings seems much more intuitive than having %concat implied for both. Afterall, does %eval for strings make sense?

Quote:
#VAR varname @a||1 would be 21

should become

#VAR varname %concat(@a,"1") would be 21

which is more intuitive than || I think, (correct me if I'm wrong, I very well might be).

Edit: My only concern is that some unforseen problem might arise with existing scripts.
Also, would there be a need for the %eval() function with this change?
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 7:20 pm   
 
There will always be a need for %eval. If you create an expression at runtime in a string and then later want to evaluate the expression stored in the string then you would still use %eval.

In other words, if you do this:

#VAR string "1+2+3"

this still just stores the STRING value "1+2+3" because of the surrounding quotes. Remember that anything surrounded in double-quotes is still a string value, just like any other language. If you do:

#SHOW @string

it will still display "1+2+3". So if you wanted to evaluate this and get 6 you would still use %eval(@string)

The proposed changes would only kick in when you are not using quotes:

#VAR number 1+2+3
#VAR number {1 + 2 + 3}
#VAR number (1 + 2 + 3)
number = 1 + 2 + 3

would all store the value of 6 in the @number variable. Notice that if you want to put spaces in the expression in the #VAR command you need to use either {} or () to surround the expression.

In the case he Hav was having questions about, it's important to understand how quotes are used for strings. If @a has the value of 2, then

#VAR @a+"1"

will perform a concat and store the string "21" in @a because of the quotes around the "1". If you just do

#VAR @a+1

then it will perform addition and store the number 3 in the variable. If you have two variables, @a and @b and do

#VAR @a+@b

then it depends on the value of the variables to determine if a concat or add is performed. And this is probably the case where you'd want to use %concat to force concat or use the

#VAR %int(@a)+%int(@b)

to force it to convert the variables into numbers and then perform the addition. But the %int function is rarely required because if both @a and @b have numeric values stored, then it will default to performing addition over concat.
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 7:23 pm   
 
Oh yeah, and mr_kent, I'm sure there will be unforseen problems with existing scripts. That's the downside to making any sort of changes. But this is a one-time opportunity to make this change. Once CMUD has been around for a few months, then I'm not going to want to make big changes to the parser like this. I'm just hoping that the number of problems caused by the change is pretty minimal. But people switching from zMUD to the CMUD beta will expect some problems...it's only when CMUD gets closer to public status that I'll need to decide if the problems effect enough people to worry about, and by then we might have a workaround or a compatibility mode of some kind.
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 8:25 pm   
 
Hmm, actually, I just had an idea that might make this a bit better and more compatible.

Looking at the above examples, how about this:

1) Putting double-quotes around the value forces it to be a string. No expansion and no evaluation. This is the same as existing behavior.
Edited:zMUD actually still expands within quotes for the #VAR command, so this would cause a difference between zMUD and CMUD.
2) Putting Braces {} around the value allows expansion, but prevents evaluation. This would result in the same as existing zMUD behavior.
3) Putting Parenthesis () around the value would cause evaluation. This would be new behavior.
4) Omitting any of the above would cause the value to be evaluated. This would be new behavior.

So, here are some examples:

Code:
a=2
#VAR test "1+@a+3"

This would behave the same in both zMUD and CMUD and would result in the string value of "1+@a+3" stored in @test.
Edited:zMUD actually stores "1+2+3" in @test, so this would be a change. CMUD would respect the quotes.
Code:
#VAR test {1+@a+3}

This would behave the same in both zMUD and CMUD and would result in the string value of "1+2+3" stored in @test.
Code:
#VAR test (1+@a+3)

In zMUD this stores "(1+2+3)" in @test. But in CMUD, this would store the numeric value of 6 in @test. Because this had such an unexpected result in zMUD, I'm guessing that very few people are using this syntax in existing scripts, so the change would effect a small number of people.
Code:
#VAR test 1+@a+3

In zMUD this stores "1+2+3" in @test. But in CMUD this would store the numeric value of 6 in @test. This is probably the case that would effect the most people. But since spaces cannot be used with this syntax without confusing the parser, I'm hoping that people have already put {} around the expression.

For the a=b assignment syntax, it would work the same. So the two statements that would change in CMUD are:
Code:
test=(1+@a+3)
test=1+@a+3

and in both cases they would store 6 in @test in CMUD.

Anyway, I think allowing {} to continue to work as it does in zMUD will help minimize script compatibility problems. It also provides an easy syntax to prevent the new evaluation changes in CMUD.

So the rule of thumb: Use {} to prevent evaluation and work the same as in zMUD, or use () for evaluation.


Last edited by Zugg on Thu Mar 30, 2006 8:30 pm; edited 1 time in total
Reply with quote
Zugg
MASTER


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

PostPosted: Thu Mar 30, 2006 8:29 pm   
 
Hmm, I just discovered that zMUD actually has some problems with quotes. I just tried the example:
Code:
#VAR test "1+@a+3"

in zMUD and it actually still stored the value of "1+2+3" in @test. I had forgotten that zMUD did this. It makes me even more convinced that this needs to be changed. It seems like if you are putting " quotes around something, then zMUD should leave it alone and treat it as a string value. I had thought that zMUD had a rule about not evaluating within quotes, but that seems to have gotten broken somewhere along the line.

So, using quotes would be another difference. In zMUD you get "1+2+3" whereas in CMUD you would get "1+@a+3"
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: Fri Mar 31, 2006 12:58 am   
 
I can understand the wish to be as compatible as possible with zMUD but perhaps this is just one of those occassions that outweighs compatability with what is appropriate. You have a chance to make things right, make CMUD script behave in the way that many other script languages work, this may be one time where you need to forget about zMUD and focus on the future, the way forward, the way things ought to be.
_________________
Taz :)
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Mar 31, 2006 1:35 am   
 
Well, yes and no. It's a very fine line that I'm walking. If CMUD isn't compatible enough with zMUD, then lots of people won't upgrade and I'll end up having to support both products for a long time. My goal with CMUD is to make it good enough that everyone will want to upgrade. So compatibility is still a big issue.

So on one hand, yes...this is the chance to "fix" all of those wierdnesses in zMUD. But I have to do it with caution, which is why I created this topic to discuss it in the first place.

The idea is to try to make zMUD friendlier to new users and less "wierd" in it's programming. New users who have never programmed before don't really effect this since they will learn whatever they need to learn. New users who have programmed before will want things to work "normally".

So, a new user who has programmed before will type

a = 1+2

and expect the value of 3 to be stored in @a. The fact that using {} prevents the evaluation doesn't really hurt this user because doing

a = {1+2}

isn't something a normal programming will think about doing. All other programming languages use () parenthesis for expressions, so adopting that same syntax in zMUD seems natural.

So, unless I'm missing something, my previous proposal still makes CMUD behave as other scripting languages do.
Reply with quote
Tarn
GURU


Joined: 10 Oct 2000
Posts: 867
Location: USA

PostPosted: Fri Mar 31, 2006 4:31 am   
 
I wrote a long post, and then thought about it in the context of #FUNC.

Now abbreviated to:

It would be perfectly reasonable to define "=" as being #MATH instead of #VAR. IMO, this would break fewer scripts than changing the behavior of #VAR.

-Tarn
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Fri Mar 31, 2006 11:14 am   
 
Actually I very much like the rules for quotes, braces, and parenthesis. As I thought about the previously suggested change method, I wondered just what some string list assignments might do if subjected to excessive evaluation. Using the the less sweeping change will keep problems to a minimum while bringing CMud into a more programmer friendly syntax.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Fri Mar 31, 2006 12:22 pm   
 
Whilst I understand what you mean with regards to having people not upgrade if scripts are made too incompatible, there's always the other way of looking at it.

"What, they've still not fixed eval? Bah, well I'm not gonna bother upgrading then"

ZMud has been around a long time, but as was said earlier, this is a great chance to correct a few things that might not be broken but aren't as intuitive as they could be (eval being a good example).

I'm actually looking forward to cmud as a good reason to rewrite old scripts that I've been too lazy to do in the past. 10th April looking a feasible release date btw?
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Fri Mar 31, 2006 3:47 pm   
 
I agree with Taz. Don't worry too much about the backwards compatibility, though it'll be nice if not everything breaks in the upgrade. I write some of the largest and most complex scripts, and if I have to go through and make some changes for compatibility, I won't be too hurt. In fact, I might be able to charge some gold sovereigns for the upgraded scripts. ;)
Reply with quote
nexela
Wizard


Joined: 15 Jan 2002
Posts: 1644
Location: USA

PostPosted: Fri Mar 31, 2006 4:05 pm   
 
This would be a good change, but one small idea to push this along, be sure to have a help file linked to #VAR that explains expansion and evaluation some people that have never programmed anything before might not have any idea what the differance between the two might be.
_________________
Zmud Support Library
Zmud Knowledge Base
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Mar 31, 2006 5:17 pm   
 
OK, I'm going to go ahead with this change and see how it works. As usual, feedback on how this works in practice will be used to tweak it during the beta period.

Also, if you think of some other "wierdness" in zMUD that should also be "fixed", please make a new thread post and let me know. As we have discussed, this is a good time to make some changes.

And Guinn, that's a very good point that I hadn't thought about. Perhaps some people are avoiding zMUD for exactly that reason.

And Nexela, I'm planning a complete rewrite of the help files and will make sure I address this issue more completely. But you won't see any new helps files for the first beta release...there is a *lot* of work that needs to be done to update the help files for CMUD, and as usual, it's taking a lower priority than getting the first beta released.

Now I'll go add a post to the ETA thread about the time schedule.
Reply with quote
SilentDawn
Beginner


Joined: 19 Jan 2006
Posts: 11
Location: Sydney, Australia

PostPosted: Sun Apr 02, 2006 11:02 pm   Don't be limited by compatability
 
I agree with Taz.

cMUD is not zMUD v 2.0, it is a completely new product.

Look at PC architecture and the limitations and inefficiencies that have been imposed in the name of compatability.

This is a one-chance opportunity to break free of redundant and confusing structures and adopt something new.

I can understand some reluctance to inconvenience those who have existing code from zMUD, but shouldn't this be outweighed by the opportunity to write simpler, easier to understand code, in cMUD?

cMUD will first be released in beta, and this will give existing users an opportunity to adapt their existing code. To assist users, you could provide a guide outlining command structure changes from zMUD to cMUD.
Reply with quote
vey2000
Novice


Joined: 21 May 2004
Posts: 32

PostPosted: Fri Apr 07, 2006 11:22 am   
 
I have a suggestion in line with the idea that this a great opportunity to make some critical changes to ZScript.

Although it would mean a bit more work for you, perhaps you could include two ZScript engines, a "legacy" one that will essentially run old code and that won't be supported by you within CMud, and a new ZScript 2.0 -- I would've said CScript, but I'm sure there's some C-based script language out there with the same or similar name -- engine that will incorporate all these new changes. Then, rather having an automatic conversion from ZScript 1.0 to ZScript 2.0 when you import your zMUD files, have it available on command and make it so you can convert only some parts at a time, such as a group of aliases/triggers/classes/etc. This way you can keep your old code running at first, and slowly convert one section at a time, while manually updating whatever needs to be changed to conform to ZScript 2.0 that the conversion program didn't catch.

This way would certainly make transition easier for those of us with a lot of code, and make it easier for you to make big changes to the language without completely breaking initial compatibility.
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Apr 07, 2006 6:38 pm   
 
CMUD already includes both scripting engines. I'm calling the engine in CMUD "zScript 8.0" vs the 7.21 version in zMUD. In other words, the version of the product reflects the version of the scripting language. So that's why the first beta version of CMUD is version 8.0 rather than 1.0.

There will be an option to control whether the new or old parser is used. When something doesn't compile, the old parser is used. As we learn more about the compatibility issues and as I come up with ways to convert old scripts, the old parser will probably eventually be removed from CMUD. Having two parsers in the long run just provides more confusion. So it's only an intermediate step so that if there is a problem with the new parser people can still play their MUD with the old parser as needed.

However, performing automatic script conversion is going to be very difficult. Script conversions requires that the script can be parsed (by the existing syntax checker) so that syntax can be properly altered. Things like the change in class specifiers (changing /varname to ./varname) is a bit easier. But handling the change in evaluation vs expansion is nearly impossible. The conversion routine would end up doing more damage than good.

What I'm mainly trying to do is make sure that common scripting stays the same, and that only some advanced features are really changed. If advanced features change, the person who wrote the script should be able to easily fix it. So that's why I'm not completely revamping the entire programming language. Just tweaking it here and there to make it make more sense.
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