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

[Fergus Henderson]

On 05-Dec-1997, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> 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.

You are mistaken.  I just tried it and it works fine on mundook,
with both cc and gcc.

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

Fine.

[Re the need to preserve purity information in goal_infos:]
> > 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.

This is a good idea, but easier said than done ;-)

Anyway, I just wanted to make sure we thought about it.
I just spend a bit of time looking for potential problems
myself, and didn't spot any.  I think we should proceed with
this change.  If you want to have a go abstracting the various
goal_info updates out after you have committed this change,
then you are more than welcome.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.