|
[Date Index]
[Thread Index]
[Author Index]
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
Prev by Date:
Reading in an ASCII file written by a FORTRAN program
Next by Date:
Re: Mathematica Question - Using DSolve with Boundary Conditions
Previous by thread:
Re: Return Ambiguity
Next by thread:
Re: Return Ambiguity
|