Re: Design by Contracts in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg93370] Re: Design by Contracts in Mathematica
- From: "Steve Luttrell" <steve at _removemefirst_luttrell.org.uk>
- Date: Wed, 5 Nov 2008 04:54:08 -0500 (EST)
- References: <geeeb9$ae5$1@smc.vnet.net> <gemjgo$4ru$1@smc.vnet.net> <gepb6q$sma$1@smc.vnet.net>
To answer your specific questions: 1) do you know of any way, in the existing Mathematica, to achieve the same result ? I am not aware of anything that is specifically provided in Mathematica as is. Why not simply define your own "safe" version of Module? Maybe based on something like this (which I haven't tested!): mySafeModule[x_, y_, opts_] := postProcess[Module[x, y], opts] In another thread I saw some mention of the use of Throw and Catch for handling error conditions. You might consider using these. 2) do you think it would help in writing more stable/debuggable code ? Yes, definitely. I'm all for using a "pre-emptive defense" in one's programming language/style. -- Stephen Luttrell West Malvern, UK "ADL" <alberto.dilullo at tiscali.it> wrote in message news:gepb6q$sma$1 at smc.vnet.net... > Thank you, Steve, for your comments. > The case you mention appears to be related to the evolutions of > Mathematica itself and to the changes in behavior of "core" functions. > In this case, I agree with you that a "design by contract" approach > would be difficult to achieve and also quite inefficient > computationally. > > Instead, I was actually thinking to the development of software by the > Mathematica users. > Just to give a picture, I was thinking to something like a couple of > new options to Module, which currently has no options, e.g.: > > Module[{...}, ..., PostPattern-> XXX, NoMatchAction:> YYY] > > where: > PostPattern (with a defaul value matching everything, like "___") > ia a pattern matched to *any* value coming out of Module > YYY[ <module result>, Hold[<module arguments>] ] is a function > which is called in case of failing pattern match with two arguments: > the Module results and the original Module arguments. > > The default action of NoMatchAction should leave the result untouched, > like Identity[#1]. > > With this structure available, perhaps one could write modules in the > normal way but benefit from the possibility to check for their outcome > and immediately stop the propagation of several types of errors, > possibly including the ones you mentioned. > > The advise I was asking to the group is twofold: > > 1) do you know of any way, in the existing Mathematica, to achieve the > same result ? > 2) do you think it would help in writing more stable/debuggable code ? > >>From a lot of discussions (and my personal experience) debugging > Mathematica code can be a trouble and making it safer since the > beginning (especially without resorting to any strong typing) might be > a nice step forward. > > Bye > > On 3 Nov, 11:24, "Steve Luttrell" > <steve at _removemefirst_luttrell.org.uk> wrote: >> Like you, I am impressed by Eiffel's "safety features". However, I have a >> counter-example that suggests that what you want to do is in general >> impossible in Mathematica. >> >> Some of my Mathematica code has been broken by changes in the way that >> newer >> versions of Mathematica represent expressions, though in every case the >> newer representation was equivalent to the older representation. My >> problems >> have arisen because I was using Part to pick out parts of algebraic >> expressions for further processing, and each time I have tried to fix the >> problem it has been broken by further representation changes in later >> versions of Mathematica. So I have learnt that anticipating the form >> (i.e. >> pattern) of Mathematica output can be problematic, and I don't use Part >> in >> this way any more. >> >> More generally it is difficult/impossible to anticipate in advance what >> the >> form of an output expression is going to be, because it is a >> computationally >> "hard" problem to prove the equivalence of two (actually equivalent but >> differently written) expressions. I am not an expert in computation >> theory, >> so I might have used the wrong technical term, but you should get the >> idea >> of what I mean. >> >> -- >> Stephen Luttrell >> West Malvern, UK >> >> "ADL" <alberto.dilu... at tiscali.it> wrote in message >> >> news:geeeb9$ae5$1 at smc.vnet.net... >> >> >> >> >A question for the experts. >> >> > I have recently met the concept of Design by Contract (TM) software >> > implementation used in the language Eiffel. It is based on the >> > conditions "require", "ensure" and "invariant" which must be met by a >> > piece of code in order to be correctly executed. It appears that this >> > concept helps building reliable and reusable code. >> >> > Now, I find some analogies of the "require" clause with the normal >> > Mathematica patterns and Condition specifications for functions. In >> > any case, this condition appears to be easily implemented. >> >> > Instead, a Mathematica implementaion of "ensure" and "invariant", >> > which are triggered by the appearance of the final outcome of a >> > function, seem to me quite tricky to implement in a systematic way. >> >> > Now I come to my questions. >> >> > Do you think that a modification to the internal Mathematica cycle by >> > adding "exit" patterns to be matched by functions' outcomes (in >> > parallel with existing "inlet" patterns which must be matched before >> > transformations) could make easier Mathematica programming and >> > debugging? >> >> > Do you think this would represent a big challenge for Wolfram >> > developers? >> >> > Thank you in advance for your comments. >> >> > Al > >