[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