[mercury-users] Native garbage collector for Mercury

Thomas Charles CONWAY conway at cs.mu.OZ.AU
Mon Sep 14 18:03:53 AEST 1998


Tyson Dowd, you write:
> On 14-Sep-1998, Thomas Charles CONWAY <conway at cs.mu.OZ.AU> wrote:
> > Peter Schachte, you write:
> > > of *which* io__state?  count, as I conceived it, takes an io__state as
> > > input, and produces an io__state as output, and you aren't allowed to
> > > change it between those points.  All parts of the io__state that are
> > > needed to implement count *must* be there when you call count.
> > > Otherwise you're cheating.
> > 
> > Ah. What you need is the semantics for fork/4 which we've worked out,
> > but I'm still in the process of writing them up. Basically, fork is
> > a cc_multi predicate that performs an "arbitary" interleaving of all
> > the updates to the io__state of a pair of closures - Fergus alluded
> > to it in his post earlier.
> 
> So in essence you are splitting the io__state into two states,
> and fork defines the order of merging of those states (i.e. arbitrary
> interleaving)?

Pretty much. The way we did it previously was to split the io__state
into a pair of lists - a list of requests to the world and a list of
responses from the world, then assuming `&' to be a (dependent) parallel
conjunction using partially instantiated modes (which of course we don't
yet have, but when we do, the resulting language will be a subset of the
pure-Prolog-plus-dynamic-scheduling which has already been given a
sane delarative semantics by others, eg Kim Marriott and Harald):

fork(A, B, IO0, IO) :-
	IO0 = Resquests0 - Responses0,
	split(Requests0, ReqsA0, ReqsB0),
	split(Responses0, RespsA0, RespsB0),
	(
		IOA0 = ReqsA0 - RespsA0,
		call(A, IOA0, IOA),
		IOA = ReqsA - RespsA
	&
		IOB0 = ReqsB0 - RespsB0,
		call(B, IOB0, IOB),
		IOB = ReqsB - RespsB
	),
	merge(Requests, ReqsA, ReqsB),
	merge(Responses, RespsA, RespsB),
	IO0 = Resquests - Responses.

Here split and merge are nondeterministic merge predicates. There
is some magic involved, since split has to know how to split the
request and response streams correctly in advance, however we can
finesse this problem by assuming that the initial state of the world
somehow contains enough information for split to know how to work
correctly.

Thomas
-- 
Thomas Conway <conway at cs.mu.oz.au>
Nail here [] for new monitor.  )O+



More information about the users mailing list