Re: Design by Contracts in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg93353] Re: Design by Contracts in Mathematica
- From: ADL <alberto.dilullo at tiscali.it>
- Date: Tue, 4 Nov 2008 06:21:03 -0500 (EST)
- References: <geeeb9$ae5$1@smc.vnet.net> <gemjgo$4ru$1@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