Re: Mathematica language issues

*To*: mathgroup at smc.vnet.net*Subject*: [mg53172] Re: [mg53136] Mathematica language issues*From*: DrBob <drbob at bigfoot.com>*Date*: Mon, 27 Dec 2004 06:41:52 -0500 (EST)*References*: <200412241059.FAA05903@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

>> As they say, without documentation nothing is a bug, because it's >> impossible to tell what the expected behaviour is. I have to agree with you there. What's going on in this thread is that (1) we have strange-seeming behavior, and (2) people are inventing explanations for it. If the explanation fits observations (or so the argument goes), that becomes the documentation. Hence there's no mystery. But it's not official documentation, so if we find an example that doesn't fit the explanation, no problem, that's still not a bug; it's just the wrong explanation. Alternatively, the language ITSELF is the documentation. So again, there's no mystery, or the mystery doesn't matter. I'm not hard to please, really; I'd just like to see a Help article for Unevaluated that gives us ANY clue what the limitations are. We keep hearing that these usages are not intended, but the documentation doesn't say that, so it's just another ad hoc theory. More specifically, if the Villegas paper is the best documentation available, perhaps the Help article should include or link to it. Bobby On Fri, 24 Dec 2004 05:59:47 -0500 (EST), Maxim <ab_def at prontomail.com> wrote: > 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 > > > > -- DrBob at bigfoot.com www.eclecticdreams.net

**Follow-Ups**:**N[] does not work inside Replace[] ?***From:*yehuda ben-shimol <benshimo@bgu.ac.il>

**References**:**Mathematica language issues***From:*Maxim <ab_def@prontomail.com>