Re: Re: Re: Return in function

*To*: mathgroup at smc.vnet.net*Subject*: [mg106107] Re: [mg106045] Re: [mg106018] Re: Return in function*From*: Leonid Shifrin <lshifr at gmail.com>*Date*: Fri, 1 Jan 2010 05:38:06 -0500 (EST)*References*: <hftbe9$cjh$1@smc.vnet.net> <200912300915.EAA17319@smc.vnet.net>

Hi Bobby, On Thu, Dec 31, 2009 at 10:26 AM, DrMajorBob <btreat1 at austin.rr.com> wrote: > Explanations hidden in technical reports do not count as documentation, and > neither do private communications between experts. (For the same reason.) > > If the behavior of Return is not a bug, it should be documented where users > are likely to see it when looking up "Return" in Help. > Agreed. You have a point, and I also think that the documentation for Return is inadequate. That said, most if not all of people participated in the discussion in this thread are advanced Mathematica users, to say the least. And although I don't know the exact circumstances and context in which the OP (Daniel) encountered this problem, I have no doubt that he could and did find a workaround even before posting the question. I think that we all ask questions like this not because we are totally stuck and see no way out, but in order to understand the system better, including its darker corners. For a system as large and complex as Mathematica, I think it is unavoidable to have a large number of such pitfalls, especially because the system is evolving. Now, there are two ways of answering this sort of questions: one is to rightly blame the documentation (which generally is by far not the worst among those for the software I use) , and another is to give some perhaps not hundred percent authoritative or "official" but reasonable explanations. I find the latter more constructive, given that it is the latter that most people with sufficient Mathematica background seem to be interested in. > The explanation below seems to be "retrospective cataloging of observed > behavior", not "designed behavior". I disagree. I think it is the designed behavior. And the fact that it has been documented (albeit in a technical report) as early as in 1992, I think speaks in favor of my guess. The problem is that the semantics of function calls is emulated in Mathematica by the rule substitution. OTOH, for the consistency of the system, Return must obey the standard mechanics of evaluation process, as any other head. Since the decision do discard Return is comming from the "external" to Return context, you can not just define built-in DownValues for Return. Moreover, since Return performs a non-local jump, you can not universally define UpValues for Return either. What are your choices then? Here is my guess. Making Return work in a block of code is not difficult - all you have to do is to define an extra rule for CompoundExpression, which will make it ignore its arguments standing after Return. In this way you avoid the complexities and overhead of checking for Return in each of the many kinds of scoping constructs. By not discarding Return at this stage you make it possible to nest (break out of nested CompoundExpression-s): In[1]:= (c; d; (a; b; Return[e]); f) Out[1]= Return[e] But this means that Return must be an idle head. Who will then be responsible for discarding Return at the end? Not Return itself, and not the scoping constructs which presumably know nothing about Return. It may be that a universal solution to this problem does not exist or is very hard to find/prove correct. The design decision concerning Return seems to have been made such in order for a user of Return to see no difference from the action of Return in other languages, *in most sensible cases*. Since the overwhelming majority of uses of Return are inside some user-defined functions (rules), a single simple rule of discarding Return generated through application of user-defined rules covers all such cases. This seems to be one of the cases where generality has been traded for simplicity, and in this particular case this looks like a very reasonable solution to me.I wonder how many beginners or even intermediate Mathematica users ever stumbled upon anything like Daniel's original example - I think very few. > > > This seems to explain the behavior of Return in all cases (at least in my >> experience). >> > > Exactly. Your next experience may be different, and you'd simply add it to > the list. > True. But notice that the list is quite short, and it summarizes experiences of several people, not just me. And somehow in the case of Return I doubt that it will grow significantly, if at all. Regards, Leonid > > Bobby > > > On Thu, 31 Dec 2009 02:15:35 -0600, Leonid Shifrin <lshifr at gmail.com> > wrote: > > Norbert, >> >> Had you followed the development of this thread and you would have noticed >> my post where I argued that this is *not* a bug, although indeed a rather >> unintuitive feature. The main authoritative source of information on this >> matter (apart from the standard documentation) seems to be the technical >> report by David Withoff named "Mathematica internals", of 1992. After >> making >> my post I was additionally informed by Fred Simons that the behavior of >> Return has been very nicely summarized by Allan Hayes back in 2002. I >> think >> this may be of general interest so I repeat it here: >> >> If Return[x] is generated as a value in Do or Scan then x is immediately >> returned; >> If Return[x] is generated as an entry in CompoundExpression or as a value >> of >> the body of a While or For loop then Return[x] (not x) is immediately >> returned; >> If Return[x] is generated as the value of a user-defined function then the >> function returns x (not Return[x]) >> Otherwise Return[x] behaves as a ordinary expression. >> >> This seems to explain the behavior of Return in all cases (at least in my >> experience). >> >> Regards, >> Leonid >> >> >> >> On Wed, Dec 30, 2009 at 12:15 PM, Norbert P. <bertapozar at gmail.com> >> wrote: >> >> On Dec 11, 3:46 am, dh <d... at metrohm.com> wrote: >>> > Version 7.0.1 >>> > >>> > Hello, >>> > >>> > I am not sure if this is a feature or a bug. If you use Return in an >>> > >>> > anonymous function, not only the return value is returned, but also >>> > >>> > "Return" itself. Consider: >>> > >>> > (If[# == 2, Return[a]; #, #]) & /@ {1, 2, 3} >>> > >>> > this gives: >>> > >>> > {1, Return[a], 3} >>> > >>> > The same thing happens with: >>> > >>> > Function[x, If[x == 2, Return[a]; x, x]] /@ {1, 2, 3} >>> > >>> > However, the following works as expected: >>> > >>> > f[x_] := (If[x == 2, Return[a]; x, x]); >>> > >>> > f /@ {1, 2, 3} >>> > >>> > Daniel >>> >>> Even though I think that it's a bad habit to use Return, it might be >>> useful at times. And since it's been in Mathematica since the version >>> 1, it should've been fixed a long time ago. >>> >>> To make the code even simpler, try (version 6.0.2): >>> >>> In[1]:= f[]:=(Return[a];1); >>> >>> In[2]:= f[] >>> Out[2]= a >>> >>> It works as expected. Now try >>> >>> In[3]:= (Return[a];1)&[] >>> Out[3]= Return[a] >>> >>> This is obviously a bug. One would expect to see "a" if Return worked >>> properly, or "1" if Return didn't work inside Function, but only in >>> definitions such as f[]:=... above. >>> >>> I get a similar result using RuleDelayed as in >>> >>> In[4]:= 2/. 2:>(Return[a];1) >>> Out[4]= Return[a] >>> >>> The documentation is also contradictory. In the description of Return, >>> there's an example that shows that Return exists only the innermost >>> loop (construct) such as Do. Much like Break[], why isn't there Break >>> [expr] instead? But in tutorial/LoopsAndControlStructures they say: >>> Return[expr] return the value expr, exiting all procedures and loops >>> in a function >>> >>> Best, >>> Norbert >>> >>> >>> >> >> > > -- > DrMajorBob at yahoo.com >

**Re: Re: Replace and ReplaceAll -- simple application**

**Re: Re: Re: Return in function**

**Re: Re: Re: Return in function**

**Re: Re: Re: Return in function**