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