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

[Nancy Mazur]

> Hi Nancy,
> 
> This change made me wonder:  how do you handle impure code?  It occurred to
> me that a foreign predicate could easily store away a term that was passed
> in, and another foreign pred could return it back to Mercury, creating a
> perfectly invisible alias.  Such foriegn predicates really should be
> declared impure and semipure, respectively.  I'm afraid this means that you
> have to assume that all arguments of every impure or semipure goal are
> aliased.  You may be able to do a little better than this, but probably not
> much.

In order to be able to answer your question, what is exactly 
meant by a foreign predicate? 

I thought that impure predicates only occur when somewhere
down deep one uses some pragma_foreign_code? I might be wrong. 
But if this is the case, as all pragma_foreign_code is always
assumed impure, in most cases we will assume all possible aliases. 
We just assume that at least the modes are correctly
declared and that the value of input variables will not be changed
(but in impure cases I guess even that is allowed?) so that we
don't have to throw top if all is input for example. 
If the handling of the pragma foreign code yields top, than this
will indeed propagate up the calltree. 

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. 

> Worse still, since foreign predicates are assumed pure unless specifically
> declared impure, it's not unlikely things like this will be done without
> being marked impure.  Of course, that woudl be a buggy program, so you're not
> obliged to get this right.

I guess (just a guessing) that such code will have some foreign_code
within. So the analysis will still generate an approximate alias-set
based on that. 

But my main problem is still: what is exactly meant by foreign predicate? 
How is this coded? 

Nancy

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------