[m-dev.] [reuse] fixes of some naughty bugs
Ralph Becket
rbeck at microsoft.com
Mon Mar 12 23:02:42 AEDT 2001
> From: Peter Schachte [mailto:schachte at cs.mu.OZ.AU]
> Sent: 12 March 2001 10:15
>
> Suppose we defined p/1 as:
>
> p(Term) :-
> Term = f(X, Y),
> X = Y,
> destructively update first argument of Term to be Y.
>
> If X and Y are big, this will free up a lot of space at the next GC. But
> 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.
Perhaps this is another case for introducing ordered conjunction and
disjunction. An idiom I see fairly often (and am guilty of myself because
it's just too painful to do otherwise) is
( if in_range(I), X = A ^ elem(I) then ... else ... )
where the conditional might well be rearranged, possibly leading to a
runtime error. Instead we'd rather be able to write
( if in_range(I) && X = A ^ elem(I) then ... else ... )
It seems to me that having ordered conjunction (&&) would be sufficient
to solve your problem (although it may be the case that you do need some
sort of extra declarations of the type you suggest to avoid problems with
automatically generated code).
> Now we just need to get people to write *all* the modes for their foreign
> code, so we can take advantage of this.
It strikes me that Nancy's optimization is not unadjacent to the compiler
automatically inferring possible di/uo modes for arguments and local
variables (and then taking advantage of them).
With the .NET stuff we're not going to hand code the interfaces to foreign
code(*) and therefore have to assume that all calls to foreign .NET code
also manipulate the io__state. Moreover, we also have to assume that
these functions can play havoc with any other compound arguments they
receive - which suggests that such things should probably be made opaque
outside Mercury space.
(*) Although the idea of adding a "pure, functional" annotation to IL
and/or adding such declarations to foreign code by hand has been mooted.
- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list