Re: Design by Contracts in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg93289] Re: Design by Contracts in Mathematica
- From: "Steve Luttrell" <steve at _removemefirst_luttrell.org.uk>
- Date: Mon, 3 Nov 2008 05:24:49 -0500 (EST)
- References: <geeeb9$ae5$1@smc.vnet.net>
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.dilullo 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 >