[m-dev.] for review: Accurate garbage collection.
Tyson Dowd
trd at stimpy.cs.mu.oz.au
Thu Jul 2 20:20:10 AEST 1998
On 01-Jul-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 01-Jul-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
>
> > library/builtin.m:
> > library/mercury_builtin.m:
> > library/std_util.m:
> > runtime/mercury_tabling.h:
> > Deep copy terms using the address of the value instead of
> > just the value.
> ...
> > deep_copy (all variants) have been modified to take
> > a pointer to the data to be copied, because some variants
> > need to be able to modify it.
>
> There are probably other calls to deep_copy() somewhere in extras/*.
>
> I think it would be better to leave the interface to deep_copy()
> as is, if necessary by making deep_copy() a forwarding macro that
> calls the function that actually does the work.
Hmmm... There are problems.
If you make deep_copy a forwarding macro,
#define deep_copy(X, ...) deep_copy_internal(&X, ...)
you need to introduce a local variable, because deep_copy is sometimes
called with a register as an argument, and you can't take the address of
a register.
#define deep_copy(X, ...) \
{ Word local_value = X; deep_copy_internal(&X, ...) }
but this doesn't work, because deep_copy returns a value.
So you need to introduce a function. Not a catastrophe, but it seems a
bit unnecessary.
Is there any driving need for this backwards compatability? I think
deep_copy will be undergoing further changes in the future, so adding a
forwarding macro probably won't work for long anyway.
If there is a need, I can add a function and some XXXs mentioning that
this is only temporary.
--
Tyson Dowd # "Bill Gates is a white persian cat and a monocle
# away from becoming another James Bond villan."
trd at cs.mu.oz.au # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd # -- Dennis Miller and Terri Branch
More information about the developers
mailing list