Zugg Software :: View topic - [2.11Pro] Use of #RETURN multiple times in a function non-intuitive to me

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I probably already know what I'm doing wrong here, but I was hoping to use logic in my functions that allowed for easier maintenance and a little cleaner code. (I plan to try a Lua function next!)

Anyway, would it be plausible to make the following function work the way a traditional function would work? Basically, I want to cut out of the function early on any one of a set of conditions, but when none of those is met I'll return the default value...

Posted: Mon Nov 12, 2007 5:06 pm

The trouble is that #return doesn't cause a function to exit.

#function omg {#return lol;#say hax}

the #say command will still execute because the function doesn't exit - #return basically just pushes a value onto the stack and that's it. I was going to post about this, but you beat me to it :P it'd be nice if it could do this, you're right.

However, you can build your function to exit itself once it reaches a return by nesting the #ifs or using #switch, so it's not that big a deal.

Posted: Mon Nov 12, 2007 5:38 pm

Just put #ABORT 0 in after the #RETURN.

[EDIT]: Since you're within an actual script block that should be #ABORT 1 to abort the whole function.

Posted: Mon Nov 12, 2007 6:21 pm

Yeah, I'm not sure about this one. I actually like being able to set the #RETURN value without exiting. This is actually how Delphi works. I Delphi functions, you do:

Result := whatever

to set the result of a function, but it doesn't cause the function to terminate. And this can be quite useful in many situations. So that's why I did it the same way in CMUD. Especially since there are already ways to abort a function. Although honestly, I've always considered using #abort (or using "break" in other languages) to be the same as a "goto" and just means your code probably isn't as well-structured as it could be. I know people still use it all the time...Delphi has "exit" and I do use it, but usually only at the beginning of a procedure or function to exit if it wasn't called with valid arguments. Using "exit" in the middle of a long routine is just asking for memory leaks and other obscure bugs unless you are religious about using try/finally blocks. Sorry for all of the Delphi references.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I avoid #ABORT like the plague after having seen it used incorrectly and causing odd side effects too many times. Smile

I figured out that it was very easy for me to just convert my #IF commands into one #SWITCH, so I'm happy with how it works now. Knowing how #RETURN works helps me code my #FUNCTIONs, and this behavior might be a good idea to note in the help file, just for those of us who come from traditional (non-Delphi Razz

) coding background.

Thanks for the replies!

Posted: Mon Nov 12, 2007 7:56 pm

I went ahead and added this to the help file.

Enchanter Joined: 09 Sep 2007 Posts: 605

Hmm... It not returns, it only sets the value will be returned - technically it is more correct statement. Fang, may be you add more complex example to the help?

Posted: Mon Nov 12, 2007 10:52 pm

Just for you, Arde, I rephrased it and added a few more examples. You're not getting a Christmas present now, just so you know.

Wizard Joined: 14 Aug 2004 Posts: 1269

Well, I agree with the complex examples sentiment. Most of the examples in zMUD were very simplistic and didn't necessarily indicate what the syntax would be in a more complex example. (So, often it was a question of trial and error.)

Adept Joined: 04 Feb 2005 Posts: 246

Hmm, if it's called #RETURN, it should return from the function at that point like every other language with a "return" directive. You can document it all you want, but you'll find people getting it wrong all the time otherwise....

Multiple #RETURNS are good for exiting loops early, and avoiding if/then/elseif statements.

And if you want the other behavior, it's easy to do with a local variable and a #RETURN at the end.

Posted: Tue Nov 13, 2007 12:22 am

You can already use #abort much like you'd use a return or break to exit a loop.

And see Zugg's post above for "every other language".

Wizard Joined: 14 Aug 2004 Posts: 1269

I have to agree with Zhiroc (changing "every other language" for "most other languages").

If #RETURN was like Zhiroc suggests, then for Zugg's example, you would just do
$Result = whatever
and then
#RETURN $Result

And actually, that looks very similar! Maybe functions could even return $Result by default if they reach the end of the code with no #RETURN statement. This would make $Result a special, reserved, local variable though.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Another vote for it seeming counter intuitive. Admittedly I've only really used Java so it's just my basis for 'normal' being different from Zugg's.

Posted: Tue Nov 13, 2007 1:28 am

Sorry, but this isn't going to change. Sorry about it being counter-intuitive for some people, but it's just something you'll need to get used to.

The way it is now, you can always add your own #ABORT if you really want it to exit. If I changed it so that #RETURN also exited all the time, then there would be no way to use it the way it is now, and I don't want to restrict that functionality. As I mentioned, being able to do stuff after assigning the return value can be very useful.

Also, using multiple #RETURN commands should *not* cause any error messages. If it is, then that's a bug I need to fix. In fact, a very common use of #RETURN is the following:

Wizard Joined: 14 Aug 2004 Posts: 1269

How about an extra parameter to #RETURN?

#RETURN [RtnVal], [True/False]
where RtnVal defaults to "" and True/False is "Now?" and defaults to True (or False if you want). If it is True, then it returns immediately. If False, then it returns at the end. Or we could use "Yes", or "1" (minus the quotes) for "Now?". [EDIT: Actually any non-zero value should work for True, except for False, obviously.]

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Edit: Whoops, writing this as Seb replied

Apprentice Joined: 11 Sep 2005 Posts: 124

I like the extra parameter option, default FALSE, return at end :)

Newbie Joined: 27 Oct 2005 Posts: 7

Posted: Tue Nov 13, 2007 3:53 am

Well, obviously my example above was a trivial example. Look, I've been programming for over 20 years, ok? Yes, I've always used Delphi/TurboPascal and not C/C++, so maybe I'm just weird. But in the example that you gave, if the programmer ever uses "exit" (or break, or whatever C uses to exit a routine prematurely), then you can end up with a function that has an undefined result. So I *always* set the default return value in my functions at the beginning.

This also helps with exception handling. If your routine gets an exception and you tell it to continue, then you still have the default function result instead of undefined.

Yes, it's also better to try/finally trap to ensure that you return a result. I use that as well. But I still have a lot of code that looks like this:

Wizard Joined: 14 Aug 2004 Posts: 1269

I don't mean to be incendiary, but:

Newbie Joined: 27 Oct 2005 Posts: 7

Wizard Joined: 14 Aug 2004 Posts: 1269

Zugg, if you really want to keep functions the way they are, I think you should at least consider renaming the #RETURN command to #SETRETURNVALUE, since that is what it actually does (and does not return). It will cause a lot less confusion and argument.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I can see both sides of this arguement. The convienence of return in C to end the function is useful, however even in C I often write it so that the return value is held in a variable from start to finish. I also programmed in Pascal, and often was irritatated at the lack of a quick out, exit wasn't allowed at the time. Having learned from that experience though I tend to write all loops, no matter what language, to have internal exit conditions as well as the external data. From an assembly standpoint the entire programming community are all liars, 1/20th of the instructions used are a form of 'goto'. Knowing that little detail since I started learning assembly, over 20 years ago, I am fairly certain of a few things:
1. #RETURN is a perfectly fine name
2. Whichever way Zugg does #RETURN is right.
3. The Wiki is not gospel, there are errors an ommisions
4. I am very likely to lock this thread
5. I haven't quite run out of patience yet

About all I can say for those that think #RETURN needs to exit is learn more diverse ways to write your code. An #IF-ELSE chain would work for Larkin's original problem. The reason it works is because he is actually doing if(not(slick&labroke&rabroke&crucified)) which has a number of logical equivalents. In this case he is looking to use this one if(not(slick)|not(labroke)|not(rabroke)|not(crucified)). The not is in the return values for those that are having trouble following. It gives just the same efficiency when coded that way as when return does a jump to end of function. Actually when a compiler is done with it the 2 forms end up nearly identical in assembly.

Posted: Tue Nov 13, 2007 11:21 am

At the risk of looking like a sock puppet, I'm afraid I agree with Viji. These things don't really make a difference, since either method lets you accomplish either way of doing things. The first time you try to make a function and it doesn't work like you expect (whichever way you expect), you'll read the help file and discover what rules it uses.

I personally have never used a language that doesn't use return to exit a function, but I don't see a problem with doing it this way, either.

And while Wikipedia is the best site on the planet, it does have a tendency, as Seb's found, to state things that happen to be true as if they were Cosmic Facts.

Enchanter Joined: 09 Sep 2007 Posts: 605