[m-dev.] Type Unfolding Mark II

[Peter Schachte]

> This is of course where it gets complicated, because we have to start
> being careful in each predicate of exactly how far the type has been
> unfolded and that may cause a lot of overhead as one converts between
> the two representations of the unfolded type.  Hopefully this will be
> recognised and we will not unfold the type.

Can't you just always unfold single-functor types?  Since there's only
one functor, you don't need to worry about a tag or a word put on the
front to specify the type.

Let's take an example

:- type point ---> point(int, int).
:- type size ---> size(int, int).
:- type region ---> region(point, size).

If R is of type region, there's no problem with R=region(Point,_), as
I can just make Point refer to the point part of R, which is to say
Point winds up referring to the same address as R.

I suppose you're going to say what about the goal R=region(P,S) where
P and S are known and we are builting R.  Firstly, this can always be
implemented with a few block transfers, so it isn't too bad.  But
secondly, when call by reference is implemented, this can (at least
sometimes) be a special case.  What I mean is that if the whole goal
is

	build_point(P), build_size(S), R=region(P,S)

then we compile a version of build_point and build_size to take the
address at which to store the parts of the term (instead of taking the
address into which to store a pointer to the term).  Voila!  Unfolded
structures with no copying.


-Peter Schachte      URL:  http://www.cs.mu.oz.au/~pets/
pets at cs.mu.OZ.AU     PGP:  finger pets at 128.250.37.150 for key
    [A computer is] like an Old Testament god, with a lot of rules
    and no mercy.  -- Joseph Campbell