MathGroup Archive 2008

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

Search the Archive

Re: Design by Contracts in Mathematica

  • To: mathgroup at
  • Subject: [mg93370] Re: Design by Contracts in Mathematica
  • From: "Steve Luttrell" <steve at>
  • Date: Wed, 5 Nov 2008 04:54:08 -0500 (EST)
  • References: <geeeb9$ae5$> <gemjgo$4ru$> <gepb6q$sma$>

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> wrote in message 
news:gepb6q$sma$1 at
> 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> 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> 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: Re: Re: Trinomial decics x^10+ax+b = 0; Help
  • Next by Date: Re: Create a cumulative list
  • Previous by thread: Re: Design by Contracts in Mathematica
  • Next by thread: Re: Design by Contracts in Mathematica