MathGroup Archive 2010

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

Search the Archive

Re: Mathematica daily WTF

  • To: mathgroup at
  • Subject: [mg114985] Re: Mathematica daily WTF
  • From: kj < at>
  • Date: Sun, 26 Dec 2010 04:02:12 -0500 (EST)
  • References: <if1o3h$p60$>

In <if1o3h$p60$1 at> Bill Rowe <readnews at> writes:

>Adding more layers of abstraction won't change this behavior.
>Additional layers of abstraction simply obscures the fact that
>Set doesn't pass on attributes.

Our brains, yours and mine, are clearly deformed in very different

Mine has been deformed by programming languages other than Mathematica,
in which assignment does transfer everything, and where one common
way to exploit localization in a dynamic scope involves starting
out by copying the global value to the local value (which is
subsequently modified, with the knowledge that all these modifications
will be effectively rolled back at the end of the dynamic scoping
construct).  Hence, it is definitely surprising to someone with
this experience to learn that one can't do this with Mathematica's
so-called "dynamic scoping" construct, namely Block.  Why?  Well,
it's ***logically obvious***, isn't it:  Mathematica's "initialization"
doesn't transfer most of a symbol's values to the LHS of the
"assignment".  (Why would anyone be surprised, I wonder...)  In
fact, this limitation severely reduces the usefulness of dynamic
scoping in Mathematica to the case where localization equals "clean

The fact that these limitations of Mathematica's so-called "assignment"
are true not only of the initialization clause of a Block statement,
but actually true *everywhere* in Mathematica is only more WTF-worthy,
not less.

In fact, I don't know of any simple way to fully copy one variable
to another in Mathematica.  It can be done, I'm sure, but not
succinctly, AFAIK.

Here's another hilarious bit:

Block[{Sin = Sin},


{HoldPattern[Sin::usage]:>Sin[z] gives the sine of z. }

Indeed, as described already, assigning Sin to Sin in the Block's
initialization clause gets me nothing useful, the local Sin is dead
as a doornail, and yet it still carries around its now totally
inaccurate, hence useless, usage message!  That's touching.  (To
be precise, the initialization shown above is not responsible for
the persistence of the messages; one would get exactly the same
results if the initialization clause had been {Sin} instead of
{Sin=Sin}.)  The utility of keeping the messages around when
everything else about the symbol has been stripped away is beyond

Bottom-line: the meanings that Mathematica puts on of bread-and-butter
programming terms like "="/"assignment", "value", and "dynamic
scope" are entirely sui-generis, and therefore the Mathematica
documentation should at least show the user the courtesy of making
this perfectly clear, rather than let him/her figure all this out
through hard knocks (in the form of "things that *should* work but


  • Prev by Date: Re: Mathematica 8 & reports / books
  • Next by Date: Re: Query available max memory (RAM)?
  • Previous by thread: Re: Mathematica daily WTF
  • Next by thread: Re: Mathematica daily WTF