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 Goto page Previous  1, 2, 3  Next
Larkin Posted: Mon Nov 12, 2007 4:20 pm
[2.11Pro] Use of #RETURN multiple times in a function non-intuitive to me
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Tue Nov 13, 2007 11:58 am   
 
Vijilante wrote:
About all I can say for those that think #RETURN needs to exit is learn more diverse ways to write your code.

I think you're slightly missing the point here. I think we're all capable of writing code that works, however #RETURN is coded. I won't be upset if I need to:
Code:
#RETURN $MyRtnVal
#ABORT 1

to return (although it is longer), or restructure the code so it exits at the end, but I do think the language is misleading and now is the best opportunity there is to fix that. I think this is where the rest of us are coming from too. Yes, people can read the manual, but what I can see happening, is people coming to the forums with problems, someone writing a function for them, them not understanding how the code works due to the obscure usage of #RETURN and then someone having to explain it, or, at least, wasted time while they figure it out themselves.
Reply with quote
Malach
Apprentice


Joined: 03 Nov 2007
Posts: 132

PostPosted: Tue Nov 13, 2007 12:30 pm   
 
This seems a mountain out of a molehill. Wasted time figuring out the syntax of a new scripting language? All languages have individual quirks and syntaxes that make them somewhat different than the others. Those who are learning those languages need to learn those quirks and syntaxes without expecting them to just conform to what they're used to because they are used to it.

#RETURN does not work the same way in zscript as it works in some other languages. As long as that is stated in the help file it seems unlikely that those with strong programming backgrounds are going to be storming the forums completely baffled and bewildered. It is not exactly rocket science. All of my programming background involved the traditional usage of #RETURN and I have no issues once I tested it a bit. I think people are overreacting.

I would much rather time was spent dealing with the remaining elusive bugs than fixing something that is not broken.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Tue Nov 13, 2007 2:10 pm   
 
I apologize for starting what has turned into a heated argument. It wasn't my intent to say that #RETURN is done wrong. I was simply asking if I had it right that this was the correct functionality and not a bug. I also just wanted to see the help file for the command updated to clarify this so that others like myself wouldn't hit the same thing and wonder about it for too long. Thanks, Fang (and Zugg)!
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Nov 13, 2007 5:29 pm   
 
OK, so I might have a solution to this mess that addresses the various issues that have been raised.

What if I rename the #RETURN to #RESULT ?

It seems like the main problem some people were having was that the name of this command made people think of the "return" function in other languages that works differently. And as someone mentioned, #RETURN doesn't actually "return" from the function. So #RESULT might be a better way of reminding people that you are just setting the result of the function and are not returning.

It's a simple, trivial change for me. Since this is still in Beta Testing, maybe it's not a big problem for people to change their existing scripts? Especially if using #RETURN instead of #RESULT will give you a syntax error.

At the risk of continuing to spend way too much time on a trivial issue, what do people think of this solution? It would take me about 10 seconds to implement.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Nov 13, 2007 6:35 pm   
 
I think so far the sides of the discussion have been "Don't mind" and "Change something" - nobody's actually been strictly defending the way things stand. So a change might be the way to go.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Asilient_1
Apprentice


Joined: 26 Apr 2007
Posts: 113

PostPosted: Tue Nov 13, 2007 6:43 pm   
 
I don't think the change to #RESULT would be too problematic. Particularly if the change for functions to return null stands for result also.

Even then, it's not too hard to just search for functions only and manually replace #RETURN with #RESULT.

EDIT: If anything, all I'd see it as is an aesthetic change, nothing more. I'm not entirely sure change is necessary, provided the help documentation explains it adequately. "Unlike the return command you may see in other languages, blah, blah."
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Tue Nov 13, 2007 7:01 pm   
 
If this will make both sides happy then ok, let it be the #RESULT command. When it will be the right time to make changes if not now?
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Nov 13, 2007 7:17 pm   
 
Asilient_1 wrote:
I'm not entirely sure change is necessary, provided the help documentation explains it adequately. "Unlike the return command you may see in other languages, blah, blah."

Check out how things are now and see if you think it needs anything adding. Just add a comment to the article (or, indeed, any help article) if you think of anything relevant.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Asilient_1
Apprentice


Joined: 26 Apr 2007
Posts: 113

PostPosted: Tue Nov 13, 2007 7:27 pm   
 
I'm not really seeing where the problem is. It seems to be explained well enough in the help file (which is where I'd imagine most would learn of the #RETURN command in the first place.)

Although, I will admit that this discussion reminds me of the whole "The pen is blue" scene from Liar Liar. >.>
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Nov 13, 2007 7:59 pm   
 
Quote:
When it will be the right time to make changes if not now?

That's exactly why I mentioned it. If I don't change it now, then it will be too late. Once 2.x is released as a public version, then there would be backwards compatibility issues if I changed it later in the future. And if changing it reduces the number of support emails and forum posts, then it's worth doing.
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Nov 13, 2007 8:05 pm   
 
Edited: OK, I've decided. #RETURN is changed to #RESULT in v2.12.

Also, since #BREAK is no longer used for the debugger, I have changed #BREAK to be the same as "#ABORT 0" and I have added #EXIT to be the same as "ABORT 1". Mostly because I really hate those ambiguous special arguments like the #ABORT command has. Makes it really hard to remember what aborts the entire script and what just aborts the current block, especially for newbies. I'm also adding #CONTINUE to cause the loop to go to the next iteration. So basically, #BREAK and #CONTINUE work the same as in C and Delphi, and #EXIT works the same as "exit" in Delphi. #ABORT will be left for backwards compatibility.

Also, instead of getting rid of #RETURN, I have implemented #RETURN the same way as in C: So #RETURN will be the same as "#RESULT value;#ABORT 1". So this makes #RETURN work the same as in other languages, and yet retains the #RESULT command for people like me who prefer the Delphi way of doing things.

If someone still has a remaining complaint after these changes, I'll just have to *bonk* you on the head Razz

Edited: Oh, and the be a bit clearer about this...#BREAK doesn't exactly work like #ABORT 0. #BREAK will break you out of the current loop, not just the current "block". So, if you have a nested #IF statement within a #LOOP, the #BREAK will abort the #LOOP and not just the #IF like #ABORT 0 would do. I think this is something else that people have been wanting (another reason #ABORT isn't really the best).

Edited Again: Also, there is a difference between #EXIT and '#ABORT 1'. '#ABORT 1' terminates the entire thread. #EXIT just exits the current script. Imagine that you have a script that calls a function. If the function uses #EXIT (or #RETURN) then the function exits and returns a value, but the calling script continues to run (again, just like in C). But if the function calls '#ABORT 1', then the function exits, but also the calling script terminates. Again, I think this is what people would expect.
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Tue Nov 13, 2007 8:43 pm   
 
Just incase someone happens to use both and does

#RESULT blah
#RETURN

then I'm guessing it'll return blah?
_________________
CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;)
Reply with quote
Zugg
MASTER


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

PostPosted: Tue Nov 13, 2007 8:45 pm   
 
Correct. #RETURN without any argument just maintains whatever result is already set. If no result is set, then the result is null.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Wed Nov 14, 2007 12:21 am   
 
Sounds great Zugg. I think this will please everyone! Smile The addition of #BREAK, #CONTINUE and #EXIT will be useful too. I assume #BREAK and #CONTINUE also work in a #WHILE block?
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Wed Nov 14, 2007 12:37 am   
 
Yay! All the reasons to avoid #ABORT are now actually corrected by using other commands. A final not so small request...get rid of #ABORT. Put it into the compatibility report with the message "#ABORT now longer recognized, please see #BREAK, #CONTINUE, and #EXIT in the help to determine which is right". Just a request.

And definitely 15 cheers for Zugg, we have useful goto's now! Hip, hip, huzzah! Very Happy
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Lina
Novice


Joined: 12 Oct 2006
Posts: 49

PostPosted: Wed Nov 14, 2007 2:27 am   
 
and now I'm even more confused than ever about functions...heh..just when I figured out how to use them too...lol
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Nov 14, 2007 10:32 am   
 
Which is the only problem with doing it this way - it's a lot of complication for not a lot of benefit. But then again, I don't think Average Joe is going to use the more complex stuff, so I guess catering to everyone is good.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Wed Nov 14, 2007 11:53 am   
 
I'm sure it will become clearer once it is properly documented.
Reply with quote
Iceclaw
Apprentice


Joined: 11 Sep 2005
Posts: 124

PostPosted: Wed Nov 14, 2007 1:11 pm   
 
Thank you Zugg!
Reply with quote
Malach
Apprentice


Joined: 03 Nov 2007
Posts: 132

PostPosted: Wed Nov 14, 2007 2:46 pm   
 
The old #RETURN would have become clearer once properly documented as well. Before it was pretty simple and even relative neophytes could figure out how to use a function pretty quickly. Now it's more complicated and while those with a programming background find it more intuitive, those without one now just have a more complicated command to try to figure out.
_________________
Intel Core2 Quad CPU @ 2.4 GHZ with Windows Vista Home Premium and 2 GB Ram
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Wed Nov 14, 2007 3:07 pm   
 
It is not complicated at all. The only command required in a function is now #RESULT. Zugg was kind enough to make all the rest for us, and most of them will be used in things other then functions.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Wed Nov 14, 2007 4:05 pm   
 
Or you can use #RETURN instead of #RESULT for an immediate exit from the function.
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Nov 14, 2007 6:36 pm   
 
Quote:
Now it's more complicated

Actually not. Use #RESULT instead of #RETURN and your function works just like it did before. Or use #RETURN if you are already familiar with how functions work in other programming languages. Ignore all of the other new features that you don't need. If you get a headache reading all of this stuff, then just wait till the Public release when it's all working and documented.
Quote:
A final not so small request...get rid of #ABORT

No. #ABORT still has it's own uses. Using #ABORT will exit from the current block. Sort of like #BREAK, but Abort also recognizes blocks like #IF. Not sure what you'd ever use it for, but it's something that you can't do with the other commands.

More importantly, using "#ABORT all" (where all is any non-zero value) will abort the *entire* script, no matter how deep into the calling stack you are. This is a very important feature and works the same as in zMUD. I'm going to document this as "#ABORT all" instead of "#ABORT 1" because I think using a string value like this makes it easier to understand what's it's doing, rather than just using 1.

Both of these are needed for backwards compatibility because there isn't any way to perform these actions with the new commands. It also wasn't completely obvious, but #ABORT was actually broken in previous versions of CMUD and was always aborting the entire script instead of just the current block. In v2.12, #abort properly works just like it did in zMUD.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Thu Nov 15, 2007 4:45 am   
 
... so if we #ABORT a #RETURN and haven't set a #RESULT do we #CONTINUE to #TRY to #BREAK Zugg's sanity, causing him to #THROW himself off a bridge with nobody to #CATCH him, #FINALLY allowing him to #EXIT to a heaven devoid of script languages? Very Happy
Reply with quote
JQuilici
Adept


Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX

PostPosted: Thu Nov 15, 2007 3:38 pm   
 
I'll pile on and say, "Thanks, Zugg!" for catering to all of our (often conflicting) opinions. I like the new changes, and I'm eager to get my hands on 2.12 and try 'em out.
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you!
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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