Re: Re: scope all wrong? in Mathematica 4.1
- To: mathgroup at smc.vnet.net
- Subject: [mg31914] Re: Re: scope all wrong? in Mathematica 4.1
- From: "Alan Mason" <swt at austin.rr.com>
- Date: Wed, 12 Dec 2001 04:13:53 -0500 (EST)
- References: <9v2607$ldc$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Hello.
1) I think that ideal behavior would be to issue a warning "argument of
function is shadowed by local variable, will have no effect" and just use
the local x. To barge right in and replace x in the body of the Module when
this x should refer to the local variable strikes me as too simplistic and
is therefore a surprise. Perversely, badly written code is not always a
waste of time, because it can reveal interesting things about how a system
operates. For example, people are always throwing crap at C compilers;
there are even contests to see who can write the most obfuscated C code.
I tried in my previous post to express what I think would have to be
changed to accommodate "ideal" behavior. In essence, some processing (and
therefore unHolding) of the RHS of := -- to determine the locals and look
for name clashes, and if neccessary preempt the pattern matcher -- would
have to occur before the value that the system has determined for the
pattern x_ on LHS is passed in to the RHS. Currently, this passing is
essentially instantaneous.
I concede that the above "ideal" behavior would have no practical benefits
(that I can think of) and it could burden all functions with undesirable
overhead. I can also see that Mathematica, unlike C, is not really obliged
to behave in ways that have been specified by outside committees.
2) My comment about the local x$9 reemerging as a de facto global (growing
wings as it were and flying the coop) does seem relevant to Fateman's
concern about scope violation and "escaping" variables. Variables like x$9
are normally off-limits to programmers outside of the subroutine in which
they are declared as local. Does Mathematica rely on the uniqueness of x$n
variable names to keep track internally of multiple versions of global rules
generated programmatically inside a Module, by using them in effect as part
of their "signature"? I know that I can change rules after the fact (i.e.,
after the scope of x$n as originally declared in its subroutine has
disappeared) by changing the x$n to which they have been "hard-wired". Of
course, no one who has used Mathematica entertains for a moment the
possibility that local variables are escaping wholesale -- this would make
Mathematica completely unusable, whereas in practice it's eminently usable
(albeit with a steep learning curve). But the observed phenomenon does seem
to be a kind of "back door" and therefore not exactly kosher...
Alan
PS. I think for clarity it would be best to include a code snippet showing
exactly what I mean here.
Here's a greatly abridged example from actual code:
\!\(\(\(setRules[sym_: D, \ delayCircleDotEvaluation_: 0]\ := \
Module[{\ h, \ symL}, \[IndentingNewLine]If[Head[sym]\ =!= \ List, \
symL\ = \ {sym}, \
symL\ = \ sym]; \[IndentingNewLine]SetAttributes[
SmallCircle, {OneIdentity, \
Flat}]; \[IndentingNewLine]a_\ \[SmallCircle]\ b_\ /; \
Head[a] === Plus\ || \ Head[b] === Plus := \
Distribute[h[a, \ b]]\ /.
h -> SmallCircle\ ; \ \[IndentingNewLine]\((a_. \ S_\_u_)\)\ \
\[SmallCircle]\ \((b_\ \ c_)\)\ := \
a\ b\ \ S\_u\ \[SmallCircle]\ c\ + \
a\ S\_u\ \[CircleDot]\ b\ c\ /; \
MemberQ[symL, \
S]\ \ && \((FreeAllQ[b, symL]\ || \
Head[b] ===
CircleDot)\);\[IndentingNewLine]];\)\(\[IndentingNewLine]\
\)
\)\)
If you run setRules and then do DownValues[\[SmallCircle], pick out the
rule involving S, and do a FullForm, you will not find S but rather symL$n
instead (its value is in fact that of S, but it is being held; Cases[rule,
symL$n, {0, Infinity}] returns {}). If you change symL$n interactively,
you will change rule accordingly. (But I thought symL$n was local! So this
really is a back door.)
A side observation possibly of interest: If we change the code in setRules
so that S is not first copied to symL (i.e., not "mediated") but used
directly in the rule, the value of S does appear when the rule is examined
using DownValues. This seems to shed some light on Mathematica's timing --
the value found for S_ is passed to RHS of := very early and is not held but
treated as "raw".
"David Withoff" <withoff at wolfram.com> wrote in message
news:9v2607$ldc$1 at smc.vnet.net...
> > 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
>