[m-dev.] Type Unfolding Mark II
pets at cs.mu.oz.au
Tue Mar 18 18:30:09 AEDT 1997
> 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
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 18.104.22.168 for key
[A computer is] like an Old Testament god, with a lot of rules
and no mercy. -- Joseph Campbell
More information about the developers