[m-dev.] Re: for review: new method of handling failures, part 1 of 6

[Fergus Henderson]

On 07-Jul-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > > 	% note: we must be careful to apply deaths before births
> > 
> > I know I probably wrote this comment, but it doesn't say why. I assume
> > that it is because a variable may have two lifetimes in adjacent 
> > conjoined scopes or something. If you know the reason, could you
> > improve the comment?
> 
> I don't know the reason. I suppose we could reverse the order, see what
> breaks, and document that :-(

Well, goal_info.m has a slightly more detailed comment:

 % ... Note that when traversing forwards
 % through a goal, deaths must be applied before births;
 % this is necessary to handle certain circumstances where a
 % variable can occur in both the post-death and post-birth sets,
 % or in both the pre-death and pre-birth sets.

> The position_info() wrapper around the code_info does have the effect of
> forcing programmers to make the distinction between the current code_info
> and a remembered position. As for deciding where new fields go, I think
> the comments in the declaration of the code_info type should be sufficient.
> The design above requires the allocation and filling of only a one-word cell;

Does it even require that?  Won't the position_info be a `no_tag' type
for which there is no runtime overhead at all?

> The alternative design that would make the most sense would be to make
> code_info have only three arguments, one each for the static,
> location-dependent and persistent fields, and make position_info just be
> the middle one of these. This design would require significantly fewer words
> but more cells to be allocated for updates, and accesses would be slower.
> Since memory profiling shows that code_infos do not account for a significant
> fraction of memory consumption, I thought access time and calls to GC_malloc
> were slightly more important. However, from a performance point of view
> the various designs are pretty close.
> 
> What do you think?

I think the current design is OK.

> > >  :- type disj_hijack_info
> > > 	--->	disj_no_hijack
> > > 	;	disj_quarter_hijack
...
> > A couple of comments that describe the meaning of the constructors would
> > be helpful here.
> 
> Is a reference to failure.html (e.g. quarter_hijack is "best case" etc),
> enough here and in the other similar cases?

Yes, IMHO it would.

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