MathGroup Archive 2008

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

Search the Archive

Re: Design by Contracts in Mathematica

  • To: mathgroup at
  • Subject: [mg93289] Re: Design by Contracts in Mathematica
  • From: "Steve Luttrell" <steve at>
  • Date: Mon, 3 Nov 2008 05:24:49 -0500 (EST)
  • References: <geeeb9$ae5$>

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> wrote in message 
news:geeeb9$ae5$1 at
>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

  • Prev by Date: Mathematica Talk at Northern Virginia Community College
  • Next by Date: Re: Trinomial decics x^10+ax+b = 0; Help with Mathematica
  • Previous by thread: Mathematica Talk at Northern Virginia Community College
  • Next by thread: Re: Design by Contracts in Mathematica