Re: "Do What I Mean" - a suggestion for improving

*To*: mathgroup at smc.vnet.net*Subject*: [mg96981] Re: [mg96961] "Do What I Mean" - a suggestion for improving*From*: peter <plindsay.0 at gmail.com>*Date*: Sun, 1 Mar 2009 04:54:29 -0500 (EST)*References*: <200902281142.GAA16641@smc.vnet.net>

Hi, this is, at first sight, very plausible and encouraging. My concern is that if you don't "say" what you mean, then you don't know what you mean. The biggest difficulty in problem solving is, IMHO, stating the problem clearly. I think you often find that if you put great effort into stating the problem precisely; the answer tumbles out with much less effort. I think this "stating the problem" thing extends even to the rules of language of the coding regime. Just my tuppence-worth; good luck with your idea. Peter 2009/2/28 David Bakin <davidbak at gmail.com>: > A few days ago I posted that Mathematica should have a "DWIM" feature - "= Do > What I Mean". > > In InterLisp, in the 80's, the DWIM facility was hooked into error messag= es, > and when invoked on a user error would poke around on the stack and in th= e > environment using some rules to describe common error situations and it > would uncover user errors and offer to correct them. Many of the error= s > were simple spelling errors and it would correct a misspelled variable na= me > if it found an unbound variable but a similarly spelled variable was boun= d > in the environment. > > Mathematica could benefit from this, and in fact, we at mathgroup could > supply the rules (and framework) as a useful group project. > > If some guru would write the framework - trapping error messages somehow, > perhaps when they were written to the $Messages channel (by replacing the > default $Messages channel with something that would hook into the DWIM > function), or perhaps with some other hook like redefining Message[] - th= en > the rest of us could supply rules for the common errors. Especially th= e > common errors we see puzzling Mathematica newbies on this list. > > I would suggest that the rules provide messages, hopefully with hyperlink= s > to the documentation. > > A true DWIM might also offer to rewrite the current expression and try it > again, but I don't know if that can be done given the hooks into Mathemat= ica > that are currently available. > > Some situations that could be addressed are: > > 1. User writes "xy" instead of "x y". Rule could inspect the expres= sion > under evaluation and find (unevaluated) symbols like "xy" of the form > "<prefix><suffix>" where both "<prefix>" and "<suffix>" were either symbo= ls > used in the expression or symbols bound in the environment. Rule would > explain the problem and offer to rewrite expression and try again. > > 2. Some expression using a user-defined function causes an error when > evaluating, or doesn't evaluate. Looking at the function, a rule finds > function calls where the function arguments' patterns include "_Integer" = or > similar but the arguments given to it are not integers. Rule points to > documentation describing argument types required by the called function. > > 3. Similar to 2 above, but it finds function calls that do numeric > evaluation only or are optimized for numeric evaluation but the arguments > given to it are symbolic. > > 4. Result returned is machine precision very close to zero (that is, > with large negative exponent), but an error message complained of > singularity, or other ill-conditioning. Rule points to documentation > explaining about machine precision, and/or singularity, and offers to ret= ry > the expression with more digits of precision, rewriting the expression to > achieve this. > > Actually, now that I think of it, the DWIM facility needs also to be invo= ked > by the user because some of these situations don't cause error messages, = but > only cause (wholly or partially) unevaluated expressions. So maybe the= user > could be trained to type a word, like "Explain[]" after he didn't get the > result he wanted and the DWIM facility would look at the In[] and Out[] > arrays to find out what he's been doing recently. > > I would be glad to contribute rules to the framework ... but I'm not yet = up > to writing the framework. Hopefully one of the gurus here will find th= is > interesting (and possible) and provide a framework. Then the rest of u= s > could contribute rules that would improve the Mathematica experience for = all > newcomers. (AES, I'm looking at you! :-) ) > > -- David > >