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: Sat May 06, 2006 7:54 pm   

Removing <> and [] in CMUD (Was: Changes to <> i
 
One of the "wierdnesses" in zMUD was the handling of the <> and [] immediate expansion and evaluation operators.

I've seen scripts with all sorts of mis-uses of these operators, where they are basically trying to force their way around various parsing problems in zMUD.

In CMUD, with the more consistent handling of "" for literal strings, {} for expanded strings, and () for expression evaluation, we no longer need the old <> and [] in many cases.

The only place that these operators are still needed (and the only place they are supported in CMUD) is when you really need to "immediately" expand or evaluate something in the middle of a different parsing mode.

For example, if you are creating a trigger or alias and need to immediately expand a variable at creation time instead of at later runtime, you can use <>:
Code:
weapon=mace
#alias ww {wield <@weapon>}

would create an alias called "ww" that has a value of "wield mace". Without the <> then the alias would have a value of "wield @weapon" which would use the value of @weapon at the time the alias is executed. This is one of the few times that you need to use immediate expansion.

In particular, you don't need to use <> when you are already in expansion mode and you don't need to use [] when you are already in expression mode.

In other words, when in normal parsing mode, you don't need either of these, and, in fact, CMUD will treat them as normal string values.

The reason for making this change is to allow easier handling of HTML tags in scripts and the command line.

For example, the #MESS command in CMUD allows some HTML tags (see zLabel documentation in zApp) and also allows multiline text. So you can do:
Code:
#MESSAGE {This is line 1<BR>This is line 2}

and you will get a two-line message. In zMUD, this was a pain to do because <BR> was getting treated as an immediate expansion. But in CMUD, we are already in expansion mode and therefore don't need the <>, so CMUD handles it properly as an HTML tag.

So, as a general rule, if you are using [] or <> syntax in your scripts, you will probably need to change them in CMUD. Usually you will just be able to remove the <> or [] or change the <> to {} and change the [] to ().


Last edited by Zugg on Mon May 08, 2006 5:18 pm; edited 1 time in total		 Reply with quote
edb6377
Magician


Joined: 29 Nov 2005
Posts: 482
PostPosted: Sun May 07, 2006 3:56 am   
 
thank god.. thats all i can say. I cant wait for the first beta. I have been holding off on script creation a lot lately until this comes out. This is exactly one of the reasons why. Its nice to see this change.
_________________
Confucious say "Bugs in Programs need Hammer"		 Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246
PostPosted: Sun May 07, 2006 1:26 pm   
 
Just to raise a counterpoint though, then you would need to know when "<>" was enabled or not, wouldn't you? And it seems like this is now context-specific, rather than part of the syntax.

So in the following:
Code:
#ALIAS test1 {#MESSAGE {Line 1<BR>Line 2}}
#ALIAS test2 {#ALIAS test3 {#MESSAGE {Line 1<BR>Line 2}}}

Would the definition of test3 try to expand the "<BR>" or not?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Mon May 08, 2006 5:16 pm   
 
Well, first I was going to post with some kludge to handle the special cases that Zhiroc mentioned. But after thinking about it for a day, I've decided that Zhiroc is right to point out this issue and that the *real* problem is that the <> and [] immediate expansion syntaxes are just bad and confusing.

CMUD is going to use more HTML and XML syntax in the future as more zApp stuff gets added to it. So it's important that HTML tags get handled properly and not parsed as immediate expansion syntax. And as Zhiroc pointed out, this HTML can be nested several layers deep.

So the more I thought about this, the more I wondered whether <> and [] were needed at all anymore. Now that we have Local Variables, it's much more straightforward to do something like this:
Code:

weapon = mace
$weapon = @weapon
#ALIAS ww {wield $weapon}

Since local variables are expanded immediately, this has the same effect as the <@weapon> syntax mentioned in the first post. And there is no ambiguity in this statement. You just assign values to local variables and then use them for immediate expansion or evaluation.

So, I think I'm just going to get rid of the <> and [] immediate syntax in CMUD. This will also give a clear cut case for what scripts need to be modified. Any script that you have which uses this syntax will need to be changed.

Let me know if anyone has additional comments on this. I can't think of a use of <> or [] that is currently needed in CMUD, but if you have an example that you don't think can be handled by the local variables, post it here.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269
PostPosted: Mon May 08, 2006 5:58 pm   
 
Some examples of where I use <> and [] that would require me to create a local variable where I do not need one in zMUD:

Alias values:
Code:
#VAR myArrayVariable.<@myVarThatTellsMeWhichIndexOfTheArrayToChange> {%-1} _nodef  // @myVarThatTellsMeWhichIndexOfTheArrayToChange is set by a pattern match from a trigger.  I have several uses for @myVarThatTellsMeWhichIndexOfTheArrayToChange...

#VAR xpstart <@xp>  // Run manually to restart my experience counter

My experience counter (or the part that deals with xp anyway) trigger value:
Code:
#VAR xplast @xp  // This seems to work in zMUD, but if I understand correctly, it will not in CMUD - I want the actual value, not a reference to another variable. @xp was set by this trigger the LAST time it ran.
#VAR xp %1
#ECHO XP Gained Since last check [@xp-@xplast] XP Gained Since last reset [@xp-@xpstart]
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Mon May 08, 2006 8:11 pm   
 
Seb, that's not what I asked. I know that you will need to create a local variable in CMUD. I was asking for posts that could not be accomplished by local variables.

Your scripts would work like this in CMUD:
Code:
$index = @myVarThatTellsMeWhichIndexOfTheArrayToChange
#VAR myArrayVariable.$index %-1 // don't need the {} around %-1 in CMUD, although it will work either way
#VAR xpstart @xp  // don't need the <> around it

and
Code:
#VAR xplast @xp  // should still be fine in CMUD
#VAR xp %1
// now you have several choices for the last line:
#ECHO XP Gained Since last check (@xp-@xplast) XP Gained Since last reset (@xp-@xpstart)
// or
$explast = @xp-@xplast
$expstart = @xp-@xpstart
#ECHO XP Gained Since last check $explast XP Gained Since last reset $expstart
// or
#ECHO XP {Gained Since last check $explast XP Gained Since last reset $expstart}
// or
#ECHO %concat("XP Gained Since last check",(@xp-@xplast),"XP Gained Since last reset",(@xp-@xpstart))

So, both of these scripts are still possible in CMUD, and in my opinion are easier to read and understand. The last line of the second example is a good lesson for everyone. When writing scripts, people need to start paying more attention to putting " around literal strings, and using () around expressions they want to evaluate. When a command allows multiple arguments, such as #ECHO or #SHOW, then you just need to put () around the expressions. But if #ECHO only accepted a single argument then you would need to choose one of the last two examples.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246
PostPosted: Mon May 08, 2006 9:03 pm   
 
I'm not sure if it's an example or not, but perhaps look at this thread.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269
PostPosted: Mon May 08, 2006 11:27 pm   
 
Zugg, I know that's not what you asked. Maybe I shouldn't have posted my examples, but I was clear about what I was posting, and I was concerned that this change might
(a) make certain scripts unnecessarily wordy;
(b) break compatibility for a quite a lot of zScripts.

Maybe I am wrong on point (b), and it will not affect many people. One option might be to disable <> and [] in preferences? Oh wait! That already exists! So why can't we just keep it how it is, and people who want to turn them off in preferences to use HTML tags can use local variables instead?

Anyway, thank you for showing us (me in particular) how to make scripts that use <> and [] work without them using local variables.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Tue May 09, 2006 3:58 am   
 
The Enable <> and [] only effected the command line in zMUD. They didn't effect scripts, and that's the problem here.

The reason we can't just have a toggle option is that this syntax completely effects the new compiler/parser. The language syntax with [] and <> is *much* more complicated (and kludged) compared to removing it. It's not a simple toggle...it effects the entire parse table that is built by Yacc for CMUD.

Also, since people will be sharing scripts, we can't just have some people using <> and some people not. Because it's a global change to the syntax parser table, you can't have one package with one setting and another package with another setting.

So, we have to decide whether or not to allow <> and [] in CMUD. That's what this thread is about.

(a) I think you can see in the examples that it doesn't get very wordy. In many cases you just remove <> and replace any [] with (). That will convert the majority of cases. In some cases, it adds local variables. It basically moves the contents of the <> into a local variable and then you use that local variable instead of <>. So the "wordiness" depends upon your variable name, but I still claim it makes your script more readable even though it's longer. I'm not concerned with script length, I'm concerned about making scripting easy. And having wierd syntax like <> and [] in scripts make them hard to read for new users.

(b) Yes, it is one of the biggest changes in terms of compatibility. But because it's a very consistent change, it actually helps people know whether or not they need to change a script. If their script uses [] or <> then it needs to be changed. They don't have to wonder whether or not it *might* work or not.

Anyone using <> and [] in their scripts is either 1) already a scripting expert, in which case these changes are problem a welcome relief, or 2) someone who got a script from someone else and doesn't know how to convert it. There are going to be lots of (2) cases where they will need to go back to the original script author and get a change, or start using a new script that is posted to the script library.

I plan to write a script conversion guide that will cover these issues along with the other CMUD changes, and hopefully that documentation will help.

But I've already been convinced by many people that it's important to make the changes in CMUD needed to make scripting easier even if it means losing some compatibility. So what I'm looking for in this thread are examples of things that cannot be done under the new syntax that could be done in zMUD.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Tue May 09, 2006 5:07 am   
 
Regarding the thread link that Zhiroc posted...

CMUD works the way the original person was trying to use zMUD, so <> isn't needed. Here are his four tests:
Code:
#VAR tmp1 {aaa bbb ccc ddd}
#VAR tmp2 {bbb|ddd}
#show {1> @tmp1}
#show {2> @tmp2}
#show {3> %subregex( @tmp1, "(bbb|ddd)", "***")}

displays the correct output as in zMUD:
Code:
1> aaa bbb ccc ddd
2> bbb|ddd
3> aaa *** ccc ***

Now, his next attempt:
Code:
#show {4> %subregex( @tmp1, "(@tmp2)", "***")}

is incorrect in BOTH zMUD and CMUD. Remember the rule: Variables are never expanded within " quotes. The " specifies a literal string, so in this case you are sending the literal (@tmp2) pattern to the regex and it does not expand this variable reference within the literal string. So this syntax will always be wrong. Remember again: variables are not expanded within quotes!
Code:
#show {5> %subregex( @tmp1, (@tmp2), "***")}

This failed in zMUD, but it works correctly in CMUD. However, it's not doing exactly what you think it is. The () tells CMUD to evaluate this as a mathematical expression. So #tmp2 is expanded to it's value "bbb|ddd" and this pattern is sent to the regex. The extra () in the original pattern puts the matching subpattern into the %1 variable, but this is not used in the %subregex function, so dropping the () doesn't matter. So it works, but only because the () in the original pattern wasn't needed.
Code:
#show {6> %subregex( @tmp1, %expand( (@tmp2)), "***")}

This failed in zMUD, but it works correctly in CMUD. But this is just like the previous example. The (@tmp2) within %expand is an expression evaluation, not a string value. So the extra () are dropped again in this case.

What this person wants is to expand the variable, but treat () as normal string values. There are two ways to do this correctly in CMUD:
Code:
#show {5> %subregex( @tmp1, "("@tmp2")", "***")}

This uses "implied concat" to concat the string "(" along with the value of the @tmp2 variable along with the string ")". It's the same as using %concat("(",@tmp2,")")
Code:
#show {5> %subregex( @tmp1, {(@tmp2)}, "***")}

This is the preferred correct syntax. The {} is a string that allows variables to be expanded. Remember that {} is just like " except that it allows variable expansion. After all, if you were trying to make a trigger in the first place, you'd use the syntax:

#REGEX {(bbb|ddd)} {whatever}

so why would you drop the {} just because you are making a function call? Again, this is something that zMUD doesn't handle correctly that CMUD does. CMUD has a much more consistent set of rules.

Regarding the suggestions made in the other thread:
Code:
#show %subregex(@tmp1, "(<@tmp2>)", "***")

You might be tempted to replace this with a local variable, but that won't help. Local variables, like any other variable, are not expanded within " quotes. So you really end up with the same situation as when trying to expand the @tmp2 variable in the first place. A local variable only gets expanded within a sub-definition of a trigger or alias, which isn't happening here.

zMUD had all sorts of exceptions to the rules. And expanding <> within quotes was one of the exceptions. After all, what if you really wanted the string value "<@tmp2>"? If <> is expanded within quotes, then you have to start escaping characters within quotes just to get literal strings, which is a complete mess.

In anycase, to summarize the issue:

a) CMUD fixes many of the problems that caused the person's %subregex to fail in zMUD. With CMUD he probably would have never needed to post this issue to the forums in the first place.

b) In CMUD, variables are *not* expanded within " quotes. But they are expanded within {}. So using {(@tmp2)} is the correct solution. CMUD is consistent about these rules. zMUD was inconsistent.

c) Using () to represent mathematical expressions will take some getting used to. The side effect of (@tmp2) just returning "bbb|ddd" is different than what you get in zMUD where parenthesis were ignored in many cases. However, again this is a consistent rule, so hopefully people will get used to it in CMUD.

d) The use of <> in the suggestions were a typical "kludge" workaround solution to try and force zMUD to do what it should have done in the first place. Those kind of situations should be more rare in CMUD.

e) Local variables were not needed and don't help in this case.
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA
PostPosted: Tue May 09, 2006 8:01 am   
 
My mud uses < and > to mark chat channel names. so the shout line would be:
Code:
Slicertool <shout> heya everyone!
<shout> Slicertool emotes something...


So copying/pasting the contents of a line elsewhere kept having < and > get stripped... if I built a trigger, I'd have to add an extra < and > to either side so that it would only strip the initial ones.

I like this change.
_________________
Ichthus on SWmud: http://www.swmud.org/		 Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269
PostPosted: Tue May 09, 2006 8:42 am   
 
OK, Zugg. I think you have convinced me. It would be really nice for things to work consistently in CMUD, so if that means losing some compatibility, I guess it's worth it. (I had some issues with %subregex I had to workaround in zMUD that I already posted earlier.) It ends up faster producing scripts if you know what will work the first time instead of spending the majority of the time fixing exceptions or creating workarounds.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182
PostPosted: Tue May 09, 2006 9:29 am   
 
I am all for the change. I have consistently turned off both <> and [] becuase they would often cause trouble during parsing of variables containing them. I can't actually think of anything that ever really needed them, and the only time I ever used them was when #EXEC was broken during one of the zMud betas.
_________________
The only good questions are the ones we have never answered before.
Search the Forums		 Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA
PostPosted: Tue May 09, 2006 5:47 pm   
 
Zugg wrote:
The Enable <> and [] only effected the command line in zMUD. They didn't effect scripts, and that's the problem here.


I'm actually pretty sure this statement is wrong with regards to zMUD 7.21. In one of my massive scripts for Achaea, I use <> expansion quite a bit. (I've since found better ways to code than to force expansion this way, but the <> script is still in wide use by many people.) In my documentation for installing and using the script, I let people know that they need to enable the <> expansion option. In fact, I get many people reporting problems to me because they get weird output from the commands and echo messages that have <> or <<>> around them. This tells me that it's not just a command-line thing and that triggers and aliases require the option, too.

At any rate, I'm really looking forward to CMUD ironing out some of the quirks to give us a more concise way to code things and get the results we want!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Tue May 09, 2006 7:16 pm   
 
Well, that might be true. Those options were only intended for the command line, but as we know, zMUD is inconsistent in how it applies these rules.
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