[m-dev.] [reuse] fixes of some naughty bugs

[Peter Schachte]

On Tue, Mar 13, 2001 at 02:27:05AM +1100, Fergus Henderson wrote:
> On 12-Mar-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> > Mercury compilers are allowed to reorder conjunctions, so there's no way
> > for a programmer to write
> > 
> > 	p(X), X = f(Y,_), q(Y)
> > 
> > and be confident the X = f(Y,_) won't be moved before the call to p/1,
> > thereby screwing up the GC possibility.
> 
> The programmer can always use --no-reorder-conj or its equivalent.

I don't think a global (or at least file-level) option placed in a makefile
is a good solution to a local problem in a source file.

> Or they can use if-then-else to force sequential evaluation in just 
> this particular spot. (Yes, a more syntactically convenient way of 
> forcing sequential conjunction would be nice.)

That's a bit better.

> But normally the programmer should just trust the compiler to do
> a reasonably good job.  If reordering X = f(Y,_) to before the call to p/1
> is going to slow the program down, then the compiler shouldn't do it.

Now we're in violent agreement.  The compiler should just do the right thing
for you, and it shouldn't do the wrong thing.  But to do this, it needs to
know that p(X) creates sharing between ground inputs.  So users need a way
to declare that a foreign predicate/function/goal does not destructively
modify its inputs, even in an equivalence-preserving way.  Or, since most
foreign code does not do that, they should be obliged to declare any foreign
code that does, and absent such a declaration, the compiler should be
permitted to assume that no sharing between inputs is introduced.  I much
prefer the second option.

> Sure, the compiler *might* do it.  But the compiler might also decide
> to allocate every floating point value on a misaligned address that
> causes a trap to the OS for every floating point access, or to generate
> code for "hello world" that links in a 2 gigabyte Java library that
> gets dynamically loaded from a web site in outer Mongolia via a 300-baud
> modem.  At some point you have to rely on quality of implementation.

Isn't that what the --(no-)misalign-floats and --(no-)mongolian-libraries
mmc options are for?

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  Remember, "Euphemisms are for the
http://www.cs.mu.oz.au/~schachte/      differently brained."
Phone:  +61 3 8344 9166                -- jamie at cdevil.unx.sas.com (James
Fax:    +61 3 9348 1184                Cooper) 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------