[m-dev.] Update library pragma C code

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Aug 4 17:26:02 AEST 1998


On 04-Aug-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> On Tue, 4 Aug 1998, Thomas Charles CONWAY wrote:
> 
> > > > These and all the others in math.m are missing `will_not_call_mercury'.
> > > I rest my case.
> > In that case I win! :-) Those problems were due to the default changing
> > (and the duplication of the c code for pred and func versions), not to
> > programmers making the wrong assumption.
> 
> I was being a bit flip, but my point was that forgetting to put in
> will_not_call_mercury is an error, too (a performance bug).  It's a less
> important bug, but it is also much, much harder to find.

I think you put the "much, much" in the wrong place --
if you said "it's a much much less important bug, but it is also harder
to find" then I might agree with you.

`will_not_call_mercury' is only an optimization that happens to
be useful for our current implementation.  For other implementations
(or other backends) it might not be important at all.  If we make
`will_not_call_mercury' the default, then we burden *all* programmers
for all future implementations with the need to remember to specify
`may_call_mercury' where necessary, or face possible core dumps that
may not even show up until they try to port to a different implementation.

I think making `may_call_mercury' the default is the right thing to do --
it means that only those who care about the performance advantage
of `will_not_call_mercury' need worry about inserting the extra
declarations and about verifying that they are correct.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.



More information about the developers mailing list