Re: Re: scope all wrong? in Mathematica 4.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg31897] Re: [mg31861] Re: scope all wrong? in Mathematica 4.1*From*: David Withoff <withoff at wolfram.com>*Date*: Mon, 10 Dec 2001 06:14:38 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com

> In general, Mathematica has complicated rules for when and how its functions > hold their arguments, which can lead to semantic surprises. Users can > change these attributes at their own risk. In particular, the right-hand > side of a SetDelayed such as uu[...] := x is normally not evaluated, and the > left-hand side is normally wrapped in HoldPattern. Just how these rules > work in conjunction with the pattern matcher is a mystery, but > they definitely are not working correctly in Fateman's first example --- > rr[x_] := Module[{x}, x = 5; Print["x is ", x]]. > The system needs to unwrap the various Holds in the right order and process > first the > first argument {...}of Module giving the locals and preempt the pattern > matcher if there is a clash. Presumably this should be done before > Mathematica's uniqueifying rules (appending $n to local variable names to > make > them unique) are performed. Could be a timing problem. I presume from all of those speculations and non-specific concerns that you suspect there is something wrong but that you aren't quite sure what it is. Is there some way that you could be more specific? Do you have any examples of "complicated rules" or "semantic surprises" that might help to explain your concerns? What exactly is "definitely ... not working correctly" about that example? Do you have a specific description of what you think that example should do, and why? What are the "various Holds" that you are referring to here? I can imagine two potential criticisms of Mathematica here, one of which might be partially valid, and the other of which is not valid at all. The potentially sensible criticism lies within the fact that you found this behavior confusing. In some abstract, ideal world, all of the things that we use, from VCR's to automobiles to computer software, would be completely intuitive, and everything would behave as expected. Any time someone is confused by Mathematica there is at least the possibility that there is something about the design of Mathematica that invites that confusion. In this example, however, I just don't see it. If I translate rr[x_] := Module[{x}, x = 5; Print["x is ", x]] into C, for example, I get int rr(int x) {int x; x = 5; printf("x is %d\n", x);} which generates a warning message in my C compiler and produces system-dependent results when I run the program. Most C programmers would (I hope) immediately see the error of using the same name both as a function parameter and as a local variable. I suppose it could be argued that there is also something wrong with C and with the many other programming languages that behave this way, but other than that, I don't see what it is about Mathematica that might lead one to expect behavior other than what is found in other languages. If anything, the behavior of Mathematica is more straightforward than other languages. At least it isn't system-dependent, and even an intermediate understanding of how Mathematica works would allow one to anticipate what this example will do. The other potential criticism, which so far doesn't appear to be valid at all, is that there is something objectively wrong with the design of this aspect of Mathematica; that the design includes a violation of some unspecified Sacred Principle that is well known to people with advanced degrees in computer language design, but that is probably beyond the understanding of everyone else; but that everyone should nevertheless be Very Worried that these problems are lurking around like a bogeyman in the dark, waiting to bite you in the middle of a large program. The reality is that there is no bogeyman, that this aspect of Mathematica is pretty straightforward, and that in all essential details these design choices have extensive precedent in other programming languages. This still leaves the subjective criticism. Is there something about the design of Mathematica that suggests that it should behave unlike other common programming languages? There were a few other examples here, but the analysis was all so broad and muddled that I hope that anyone who is interested will follow up with a more specific question. Dave Withoff Wolfram Research