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

[Peter Schachte]

> > That's not the case currently (at least on the main branch).
> > Currently pragma_foreign_code is assumed pure.
> 
> No, not within my analysis: they are implicitly assumed as dangerous 
> code, and treated as `can potentially do anything'-code. 

Perhaps that is too conservative.  As I said, foreign code is dangerous
because it is assumed pure and users are never forced to think about it by
being asked to promise that they are pure.  Nevertheless, pure predicates
are meant to be pure, and if you are not entitled to assume that they are
for fear of erroneous user code, then the concept of purity is pretty weak.

This leaves one question, though:  is it fair to call a predicate pure if it
destructively modifies a term in a way that leaves it equal to what it
originally was, but may create new aliases?  Eg, consider a predicate
eq(pair(T)::in,pair(T)::in) that, after verifying that its arguments are
equal, destructively replaced both arguments of the first pair with the
corresponding arguments of the second.  This is semantically pure, but
operationally impure.  Would I be wrong not to declare it impure?  Do we
need subtler shades of purity for this, or do we want users not to have to
worry about operational impurity?  Or do we want to forbid such
equality-preserving destructive modification of terms?

It would be good if you could use a predicate's purity to save you from
having to approximate it as top.

> Concerning your remark about doing better than asssuming all possible
> aliases. At this moment we're really handling it very roughly: we
> just say top, and any operation with a top-alias will always result in top. 
> Better solution: as the number of variables such code is called
> with is limited, you know this can only introduce aliases between
> those variables. One could work with top(set(prog_var)), stating 
> that there might be any kind of aliases between the variables of
> the set. 
> An even slightly more precise solution could be computed when taking
> into account the types of the variables involved. As aliases
> can only occur between two cells of the same type, we could try
> to extensively generate those possible aliases. These aliases might
> be difficult to generate with complex types, but it might be
> worthwhile in order not to loose too much information. 

I assume you're computing term aliases, rather than variable aliases, so
groundness doesn't help you?  Do you consider two terms aliased only if they
live at the same address (they cohabitate), or only if some part of one may
cohabitate with some part of the other?  If it's the latter, then you need a
weaker optimization, like saying two terms can be aliased only if their type
trees share some type(s).

But whether even that is ok or not is also unclear.  Suppose two ground terms
have different types but identical representations (the same size and bit
pattern).  I can't see why it wouldn't be correct for them to cohabitate.
Does the Mercury language forbid it?  I can even imagine an aggressive
Mercury compiler putting them in read-only memory and compressing that space
by sharing as much representation as possible.  I can also imagine a term
serializer (code to write out a term to a file in compact binary
representation) might create such inter-type aliases.


-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  The end of the human race will be
http://www.cs.mu.oz.au/~schachte/      that it will eventually die of
Phone:  +61 3 8344 9166                civilization.
Fax:    +61 3 9348 1184                    -- Ralph Waldo Emerson 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------