Mathematica language issues
- To: mathgroup at smc.vnet.net
- Subject: [mg53136] Mathematica language issues
- From: Maxim <ab_def at prontomail.com>
- Date: Fri, 24 Dec 2004 05:59:47 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Naturally, the question of the documentation is very important. As they
say, without documentation nothing is a bug, because it's impossible to
tell what the expected behaviour is. Sometimes even the most basic
functions are not fully documented. Take the simplest example: in what
order does Cases search for matches? It turns out that it goes from level
-1 up. Suppose you want to incrementally find and process all occurences
of _f in an expression, and you want either to start with subexpressions
which do not contain nested _f or, on the opposite, you want to start with
the outermost occurences. This problem can be solved very easily using
Cases: you have to take either the first or the last element returned by
Cases, e.g. Cases[f[f[1]], _f, {0, -1}][[1]] and Cases[f[f[1]], _f, {0,
-1}][[-1]] respectively. However, there is one drawback: you have to rely
on the assumption that Cases will work the same way in the next
Mathematica versions. It doesn't say anywhere that Cases is guaranteed to
preserve this order. Similarly, many people had to learn the differences
between ReplaceAll and Replace the hard way.
Even when we're talking about inconsistencies in the language, there's all
the more reason to describe the limitations or potential pitfalls in the
documentation. In my opinion, the pattern matching examples in my original
post show definite inconsistencies. It is simply ridiculous when a + b + c
/. a + b -> 0 finds a match and a + b + c /. s : a + b -> 0 doesn't.
However, some issues with pattern matching were discussed in this group
several years ago, and nothing has changed since then. Perhaps it was a
deliberate choice not to make any changes, but those issues are not even
mentioned anywhere in the documentation.
Finally, there are some issues which can only be called defects of the
language, some of the most serious being related to scoping, such as the
last example discussed at
http://forums.wolfram.com/mathgroup/archive/2003/Oct/msg00500.html :
Module[{f,g},
f[x_] := Module[{y = 1}, x];
g[y_] = f[y]
]
This shows that it is impossible to create a truly local variable in the
function definition: whichever name you choose for the local Module
variable in the definition of the function f, under certain conditions the
definition will not be identical to f[x_]:=x. (Strange as it may sound,
the simplest workaround for this is to never ever use Set and Rule.)
Needless to say, this behaviour is not documented; however, in this case
no amount of documentation will improve matters, because we still have a
defect in a fundamental part of the language. I can't see any
justification for keeping this sort of thing unchanged: even the
compatibility doesn't seem to be an issue here because I doubt anyone
purposely made use of this 'feature'.
Maxim Rytin
m.r at inbox.ru
- Follow-Ups:
- Re: Mathematica language issues
- From: DrBob <drbob@bigfoot.com>
- Re: Mathematica language issues