MathGroup Archive 2004

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

Search the Archive

Mathematica language issues

  • To: mathgroup at
  • Subject: [mg53136] Mathematica language issues
  • From: Maxim <ab_def at>
  • Date: Fri, 24 Dec 2004 05:59:47 -0500 (EST)
  • Sender: owner-wri-mathgroup at

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 :

   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

  • Prev by Date: Re: Re: Sequential evaluation of lists
  • Next by Date: Re: Re: Mathematica language issues
  • Previous by thread: Re: Re: Mathematica language issues
  • Next by thread: Re: Mathematica language issues