[mercury-users] tuple syntax

[Peter Schachte]

On Thu, Nov 11, 1999 at 03:11:14PM +1100, Robert Ernst Johann JESCHOFNIK wrote:
> On Thu, 11 Nov 1999, Peter Schachte wrote:
> 
> > Right.  There's been some discussion of "type unfolding" (or whatever
> > you want to call it; ie, when a term contains an argument A of a type
> > with only one alternative, replacing A with all the arguments of A).
> > This is a nice, general optimization (that unfortunately can lead to a
> > slowdown in some cases) that would solve this problem with tuples
> > quite nicely, and could be beneficial in other cases, as well.
> 
> Hrm. Perhaps a pragma could be added stating that this type should (or
> possibly should not) be `unfolded'.
> eg
> 	:- pragma unfold(tuple/2).
> 	:- type tuple ---> (A,B).

Trouble is, you wouldn't want to unfold all tuples.  Suppose we had
types:

	:- type (A,B) ---> (A,B).

	:- type person_list == list((string,int,float)).

There are two sensible ways we might want to do the inlining.  I'll
describe representations using C syntax, since that's easier than
trying to draw a picture.  We'd have a tuple structure like:

	struct person {
		char *name;
		int age;
		float weight;
	};

But then we could define person_list as either:

	struct person_list {
		struct person this;		// inline person struct
		struct person_list *next;
	};

or

	struct person_list {
		struct person *this;		// pointer to person struct
		struct person_list *next;
	};
	
One disadvantage of the former, ie inlining, is that when you
construct a person struct before the list element it will be a part
of, you have to copy all 3 members, whereas with the latter you only
need to make a pointer point to it.  This disadvantage can often be
eliminated by using a similar optimization: unfolding fixed structures
across predicate/function calls.  Ie, passing an n-tuple as n separate
arguments, so you simply don't constuct the structure ahead.

OTOH, when you create the person struct at the same time as the list
node, you only have to allocate and write 4 words of memory, rather
than 5.  If after creating the former version of a perons_list struct
p it is necessary to use the person struct within it, it is always
possible to pass &(p.this).

The only other disadvantage I can see to unfolding structures arises
when you want to destructively modify an inlined structure.  But I
don't think this is such a big problem because usually you'll also
want to modify the structure it's inlined into.  And anyway, Mercury
doesn't support destructive modification of discriminated union types
yet.


-- 
Peter Schachte                     I don't have any solution, but I
mailto:schachte at cs.mu.OZ.AU        certainly admire the problem.
http://www.cs.mu.oz.au/~schachte/      -- Ashleigh Brilliant 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------