Re: Re: Return Ambiguity
- To: mathgroup at smc.vnet.net
- Subject: [mg97543] Re: [mg97502] Re: Return Ambiguity
- From: DrMajorBob <btreat1 at austin.rr.com>
- Date: Sat, 14 Mar 2009 18:17:46 -0500 (EST)
- References: <200903121041.FAA27085@smc.vnet.net> <gpdab1$jq0$1@smc.vnet.net>
- Reply-to: drmajorbob at bigfoot.com
> A line of code at the top of a function that disposes of an unwanted > case: If[condition,Return[$Failed]]; is at least arguably easier to read > than an If[....] that spans the rest of the function. For complicated functions, I prefer separate patterns, something like: f[x_,y_]/;x<y:= (x-y)^2 f[x_,y_]:=x-y It separates disparate situations better than the comma in an If ever could. True, in my "toy" example, If alone is clear enough: f[x_,y_]:=If[x<y,(x-y)^2,x-y] But Return just looks silly: f[x_,y_]:=If[x<y,Return[(x-y)^2],Return[x-y]] In cases complex enough that Return helps, I think separate patterns are clearer. "It all depends" is the correct answer overall, I'll grant you, but newbies who frequently use Return will create spaghetti code. Return is, after all, Goto "an exit of the enclosing construct"... and Raffy has shown us how ambiguous that might be... so you have Goto AND ambiguity. Bobby On Sat, 14 Mar 2009 05:40:44 -0500, David Bailey <dave at removedbailey.co.uk> wrote: > DrMajorBob wrote: >> Don't use Return at all. It's poor style and will encourage bad habits. >> >> Just say, "No!" to Return. >> >> Bobby >> >> On Thu, 12 Mar 2009 05:41:53 -0500, Raffy <raffy at mac.com> wrote: >> >>> How do you determine how far Return actually returns? I have avoided >>> using this function after having difficult getting it to return to the >>> proper level of execution. >>> >>> In general, does it return to the nearest held expression? >>> The documentation is really ambiguous. >>> >> >> >> > I hate the kind of programming advice that reads like dietary leaflets, > or a sex manual from the 1950's - full of don't's and tut-tut's! > > All those commands like Return, While, Do, (but maybe not Goto!) have > their place. Sometimes the logic of a program is more transparent using > one of these deprecated constructs. Different programmers may prefer > different styles, and depending on their problem, efficiency may not > even be an issue. > > A line of code at the top of a function that disposes of an unwanted > case: If[condition,Return[$Failed]]; is at least arguably easier to read > than an If[....] that spans the rest of the function. > > David Bailey > http://www.dbaileyconsultancy.co.uk > -- DrMajorBob at bigfoot.com
- References:
- Return Ambiguity
- From: Raffy <raffy@mac.com>
- Return Ambiguity