MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: scope all wrong? in Mathematica 4.1

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...


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] ===


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> wrote in message
news:9v2607$ldc$1 at
> > In general, Mathematica has complicated rules for when and how its
> > hold their arguments, which can lead to semantic surprises.  Users can
> > change these attributes at their own risk.  In particular, the
> > side of a SetDelayed such as uu[...] := x is normally not evaluated, and
> > 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
> > 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
> > 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

  • Prev by Date: RE: Interactive simplifying
  • Next by Date: Re: Trouble with Splice for Java (i.e. there is no JForm)
  • Previous by thread: Re: Re: scope all wrong? in Mathematica 4.1
  • Next by thread: Re: Re: Re: scope all wrong? in Mathematica 4.1