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: Fri Apr 21, 2006 1:23 am   

#NEWVAR discussion
 
I was thinking a bit more about the #NEWVAR command last night in the shower.

To refresh your memory, the idea is to have a new command for *creating* new variables, compared to the existing #VAR command which can both a) change the value of an existing variable or b) create a new variable.

The proposed syntax for #NEWVAR was this:

Code:
#NEWVAR varname type [optional-initial-value]
e.g. #NEWVAR hp integer 123
#NEWVAR name string ""

OK, so this is fine and already part of CMUD. But since most of the time you just want to declare and initialize the variables and might want to declare multiple variables at once, the above syntax is a bit verbose.

I was thinking about an additional syntax similar to C:
Code:
#STRING name race spell
#INTEGER hp maxhp mana maxmana
#FLOAT varname
#LIST friends

In other words, we have new commands for each variable type and you can list as many variable names as you want to declare. The #STRING could be shortened to #STR and the #INTEGER can be shortened to just #INT just like normal commands.

Would this be useful? It's trivial to implement, so I thought I'd see what people thought.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Fri Apr 21, 2006 2:18 am   
 
Yes!

Especially if you support the "#INT $blah = 2" syntax as most people are familiar with.

Make the '=' sign optional, so "#INT $blah 2" also works, but I think most people would prefer to be able to specify the '='.

I mean it's kinda weird that it's not "int blah = 0;" but I can cope, it's zScript, not C++ ;)

Will it be '#float' or '#double'? Or both? I prefer double myself. I guess they are technically two different things, so if you have floats and doubles, then that makes sense to have both.

What about the 64 bit math? Will #INT be 32 bit and #LONG be 64 bit?

Also can #STRINGLIST be shortened to #STRL?
Reply with quote
Tornhelm
Beginner


Joined: 24 Nov 2002
Posts: 20
Location: Australia

PostPosted: Fri Apr 21, 2006 3:40 am   
 
On behalf of those of us who are nowhere near as coding savvy as Rainchild or Zarquan or most of the other guys with high post count - it would be nice, as long as the documentation was nice and complete so we could try and remember what to use when. Current mudding belief is that if you want to learn how to code well you use something like Mushclient, but if you want something thats relatively easy to learn but is still robust, powerful and capable of pretty much anything you use zMUD and thats something I wouldn't like to see disappear with CMUD.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Apr 21, 2006 4:12 am   
 
More concise, a better conveyance of the information and the intended purpose, I likey! I assume declaration+assignment with the multiple variables would be possible, too? May want/need the requirement of at least the equal sign if not some sort of bracketing rather than assuming that the next word is the value of the variable:

#INT hp=5 {maxhp 22} {mana=35} count

Speaking of variable typing, would STATIC be feasible as a feature?
_________________
EDIT: I didn't like my old signature
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Apr 21, 2006 4:46 am   
 
I'm not sure I understand what you mean by "STATIC". What are you looking for here?

Also, I didn't intend #INT, #STR, etc to also set values. I'd like people to stick with normal variable assignment for values. The idea is that #INT, #STR etc would "declare" the variables to the compiler, much like

int varname;

does in C/C++. These are compiler declarations and not really runtime statements for setting values. But I guess if the demand was there, then I could add it at some point.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Apr 21, 2006 5:38 am   
 
Hmm, surprised you've never heard the term...maybe Delphi/C++ use different terminology or simply don't use this concept. Basically, a static variable is a local variable with global persistence. As a local variable, it's only available to whatever function created it. Like a global variable, however, it stays in memory once that function has finished executing this iteration.

I've mostly seen static variables used as counters, but they can be for just about anything.
_________________
EDIT: I didn't like my old signature
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Fri Apr 21, 2006 10:11 am   
 
Personally, I almost never create a variable from within my scripts. I do all my variable creation in advance. I can see that I will be doing some variable declaration in my scripts to take advantage of the local variables, but beyond that I can't really see too much need to create variables all the time. So I would perfectly happy withe the new commands here as long as they recognize the local $ indicator and did a basic intitialization of 0 and "".
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Tarn
GURU


Joined: 10 Oct 2000
Posts: 867
Location: USA

PostPosted: Fri Apr 21, 2006 2:17 pm   
 
Vijilante wrote:
Personally, I almost never create a variable from within my scripts. I do all my variable creation in advance. I can see that I will be doing some variable declaration in my scripts to take advantage of the local variables, but beyond that I can't really see too much need to create variables all the time. So I would perfectly happy withe the new commands here as long as they recognize the local $ indicator and did a basic intitialization of 0 and "".


I agree, but the most likely use seems to be inside packages, where the additional clarity might have some benefit. Has someone else already asked for a %typename function?

Re: Static variables - in other languages, they're mostly useful in class instances, which zMud doesn't really have.

-Tarn
Reply with quote
Zugg
MASTER


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

PostPosted: Fri Apr 21, 2006 4:38 pm   
 
Delphi doesn't have "static" variables either. They are either global, or local to a routine or class, or a data field of a class. But I know what you are talking about. Unfortunately, there is no way to have "static" local variables. Local variables exist on the runtime stack and they go away when the routine ends. The only way to have persistence is to store the data into the internal variables structure in CMUD, which is basically the same as the normal variables in the database.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sat Apr 22, 2006 1:03 pm   
 
I'd really like the #INT /etc to allow assignment ... in c/c++/c# you can go:

int i = 0;
string foo = "bar";

I mean you can go:

int i;
string foo;
i = 0;
foo = "bar";

or in CMUD

#INT $i
#STRING $foo
#VAR $i 0
#VAR $foo "bar"

but that's a waste of time/lines/typing... I mean 99% of the time you create a variable, especially a $temporary variable, you will want to assign a value to it right then and there

I see the #INT/etc more like a combo between the #VAR command than the #NEWVAR command - create the variable if it doesn't exist, and set a value if you want.

I would like to see the ability to do both local and normal variables with it eg:

#INT @hp = 123
#INT $i = 0
#STRING foo = "bar"

And as matt suggested, it would be nice to be able to do multiple assignments on the one call - eg:

#INT $i = 0, $j = 1, @hp = 123, @maxhp = 444

Surely a whole lot better than writing:

#INT $i
#INT $j
#INT @hp
#INT @maxhp
#VAR $i 0
#VAR $j 1
#VAR @hp 123
#VAR @maxhp 444

Not only is it less confusing when debugging to do the assignment at the time of the variable's creation, but it makes the scripts a lot more compact too.
Reply with quote
dbsexton
Newbie


Joined: 19 Mar 2006
Posts: 6

PostPosted: Sat Apr 22, 2006 3:33 pm   
 
Rainchild wrote:


#INT $i = 0, $j = 1, @hp = 123, @maxhp = 444

Surely a whole lot better than writing:

#INT $i
#INT $j
#INT @hp
#INT @maxhp
#VAR $i 0
#VAR $j 1
#VAR @hp 123
#VAR @maxhp 444



I know I'm not a guru here, but it seems you may have choosen the worst way to write that. If I'm reading Zugg's post correctly, he is suggesting that #INT could take multiple variables and that normal variable declarations could be made after that.

So you could write "#INT $i = 0, $j = 1, @hp = 123, @maxhp = 444" as

#INT $i $j @hp @maxhp;
$i = 0;
$j = 1;
@hp = 123;
@maxhp = 444;

I know it's not as short as the C syntax, but for Zugg's part, I'm guessing he has to take in to account the extra effort vs the reward. The only duplication in the way I wrote it is the variable names since you can actually just remove the line breaks all together and it would still work.
Reply with quote
Zugg
MASTER


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

PostPosted: Sat Apr 22, 2006 5:03 pm   
 
Also, keep in mind that I don't want people to get completely carried away with variable "types". If you are assigning 123 to a variable, then CMUD already knows that it's an integer. You only need to specify types when there is ambiguity. I don't want CMUD scripts to start getting to complicated and looking like a C program...this will turn off novice users who are drawn to CMUD because it's supposed to be easier to script than a formal programming language.

Also, you need to watch your syntax when using the @ character. Your example of

#VAR @hp 123

and

@hp = 123

are wrong. The $ is needed for local variables to distinguish them from normal variables with the same name. But with normal variables, you don't use the @ unless you are doing indirect variable assignment. In other words, the correct syntax is still:

#VAR hp 123
hp = 123

If you use @hp, the CMUD is fetching the value of @hp and then using that value as the name of the variable to set.

Finally, remember that you do NOT have to declare a variable before using it. The purpose of #NEWVAR, #INT, #STR, etc was to force the creation of a new variable in the current class without performing any search to see if a variable already existed in a parent class. The intent was not to start making you declare everything. In a script, if you do something like this:

$local = 123

then this creates a new local variable called "local" right then and there and assigns 123 to it. There is no need to declare it with #INT or anything.

After reading the confusion that this has all caused, I'm tempted to leave out the #INT, #STR, etc commands and just stick with the normal type-casting functions. After all, if you want to assign 123 as a *string* to a variable, you can already do this:

#VAR strvar %string(123)

and, of course, you can still use #VARTYPE to change the type of any variable to something else.

I know that you all mean well in your suggestions. But I just can't completely change the CMUD syntax into something completely new and I can't have CMUD looking more and more like C/C++. For example, in the suggestion:

Code:
 #INT $i = 0, $j = 1, @hp = 123, @maxhp = 444

there are several problems. The first problem, of course, is the @ that I mentioned above. The @ is used for variable *expansion* and is not used when you are just refering to the name of a variable. But the main problem with this is that it violates all of the normal zMUD syntax rules. zMUD uses spaces to separate arguments to commands (like #INT), similar to how Visual Basic uses spaces for procedure calls. So, the comma between the arguments are wrong, and all of the extra spaces around the = are wrong. All of these things violate the normal syntax rules for zMUD.

Sure, it might seem like this could be easily fixed, but that's not the case. The new compiler needs consistent rules for syntax. I'm trying to minimize the number of kludges and special cases in the new parser. So I can't just go and create some brand-new syntax for a command. The compiler is set up to handle a certain number of argument "types" for commands: strings, expressions, etc (you see these types in the F1 help for a command). The compiler doesn't know anything about what the command itself does.

Anyway, I think for now I'm going to leave out the #INT, #STR, etc. I'll have #NEWVAR as described in the past, and #VARTYPE, but that will be it for now. During the Beta we'll see how things go and see if something else is really needed. But right now I think the extra commands will add more confusion than function.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Tue Apr 25, 2006 2:53 am   
 
Quote:
#VAR strvar %string(123)

I think it needs to be kept as simple as possible. I don't see separate commands (#INT, #STRL etc) as necessary for this. On the other hand, being able to do:
#INT hp mp maxhp maxmp
Is much more eloquent than a separate line for each, and I -guess- that some people will write scripts with multiple ambiguous variables. I don't see that it will be often though. I certainly don't see it happening often, if ever, for myself.

So why not have only one command that is alternative to both #VAR and var=

#ODDVAR vartype var1 var2 etc varN
eg
#ODDVAR integer hp mp maxhp maxmp

(no, I'm not serious about the name of that command, I just chose it to stress the point that it would not be often necessary, but still exists to keep people happy)
Reply with quote
Daganev
Beginner


Joined: 11 Jun 2006
Posts: 20

PostPosted: Sun Jun 11, 2006 11:20 pm   
 
Uggg!

Why are you making people learn about types for zmud?

zmud was my gateway into programming, if I had to know about the difference between an int and string, I doubt I would have gotten started.

Also, how would this work if you need to make a new package?

#package GUI ?

hmm, just read some things and see my concerns are allready taken care of. Well, just wanted to remind you how great your product is a gateway drug to coding.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jun 12, 2006 12:39 am   
 
Did you read the whole thread (and some other threads)? CMUD is not requiring types. They are an optional feature to allow better control in complex situation when the type of a variable matters. I am not implementing the #INT, #STR, etc. Just #NEWVAR.
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