[m-dev.] Diff: Make Mercury cope with impure code (part 2/2)

[Peter Schachte]

On Sat, 29 Nov 1997, Fergus Henderson wrote:

> As I said last time: why not "max = INT_MIN" instead?
> (You'd also need `:- pragma c_header_code("#include <limits.h>")'.)

I didn't do this because (I was surprised to find that) limits.h on mundook
doesn't define INT_MIN et al.  But I've made the change anyway. 

> > %  XXX The current implementation doesn't handle impure functions.  The main
> > %      reason is that handling of nested functions is likely to get pretty 
> > %      confusing.  Because impure functions can't be reordered, the execution
> > %      order would have to be strictly innermost-first, left-to-right, and 
> > %      predicate arguments would always have to be evaluated before the
> > %      predicate call.  Implied modes are right out.  All in all, they just
> > %      won't be as natural as one might think at first.
> 
> True, but semipure functions might be quite desirable...
> 
> How much extra work would it be to implement impure/semipure functions?

Impure functions would be quite a bit of work, I think, getting the order of
execution right.  Semipure functions wouldn't be as bad.  I think it's worth
getting impure/semipure predicates checked in first, and then think about
functions later.

> > %			Check purity of a single predicate
> > %
> > %  Purity checking is quite simple.  Since impurity /must/ be declared, we can
> > %  perform a single pass checking that the actual purity of each predicate
> > %  matches the declared (or implied) purity.  A predicate is just as pure as
> > %  its least pure goal.  While we're doing this, we attach a `feature' to each
> > %  goal that is not pure, including non-atomic goals, indicating its purity.
> > %  This information must be maintained by later compilation passes, at least
> > %  until after the last pass that may perform transformations that would not
> > %  be correct for impure code.
> 
> I suspect that you have just introduced a significant number of bugs :-(

Quite possibly.  I looked at all the calls to goal_info_init as you
suggested, and couldn't find any that looked like they would screw things
up.  But I didn't look carefully enough to really understand all that code,
so I may have missed something.  And it's possible the purity info is
getting lost some way other than through a call to goal_info_init.

> Any ideas on how we can verify that the existing compiler passes
> preserve the purity feature in goal_infos?

No.  But I think it would be worthwhile to somehow be more systematic in the
creation of hlds_goal_infos.  There's too much code that creates an "empty" 
one, and then sets the field or two that seem to be of interest.  It would
be safer to abstract this out into a few specialized interfaces for various
cases, particularly if they pass in hlds_goals or hlds_goal_infos from which
to get the extra info, rather than just a term__context.  Features aren't
used for much now (just `constraints' and purity, and I don't think
constraints are used at all), but they could be useful for lots of different
kinds of things, so I think it's probably worthwhile to make sure they're
handled appropriately throughout the code.  I've tried to do that for
purity, but there really needs to be an abstraction so that when the next
interesting feature is added, there's one module to look in to make sure it
gets maintained throughout the compiler.


-Peter Schachte			| Patriotism is the last refuge of a
pets at cs.mu.OZ.AU		| scoundrel. -- Samuel Johnson, 7 Apr. 1775 
http://www.cs.mu.oz.au/~pets/	| 
PGP key available on request	|