[m-rev.] for review: Remove mentions of 'dead' and 'mostly_dead' from reference manual.
Julien Fischer
jfischer at opturion.com
Sat Aug 5 15:48:15 AEST 2017
Hi Peter,
My preference would be to use 'dead' instead of 'clobbered'.
I think the former is a better name.
Julien.
On Sat, 5 Aug 2017, Peter Wang wrote:
> doc/reference_manual.texi:
> Use 'clobbered' and 'mostly_clobbered' everywhere instead of the
> synonyms 'dead' and 'mostly_dead'.
> ---
> doc/reference_manual.texi | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index e837e9e..d7d78ca 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi
> @@ -3281,7 +3281,7 @@ and @code{bound(@dots{})}), Mercury also provides ``unique'' insts
> @code{unique} and @code{unique(@dots{})} which are like @code{ground}
> and @code{bound(@dots{})} respectively, except that they carry the
> additional constraint that there can only be one reference to the
> -corresponding value. There is also an inst @code{dead} which means
> +corresponding value. There is also an inst @code{clobbered} which means
> that there are no references to the corresponding value, so the compiler
> is free to generate code that reuses that value.
> There are three standard modes for manipulating unique values:
> @@ -3294,7 +3294,7 @@ There are three standard modes for manipulating unique values:
> :- mode ui == unique >> unique.
>
> % destructive input
> -:- mode di == unique >> dead.
> +:- mode di == unique >> clobbered.
> @end example
>
> Mode @code{uo} is used to create a unique value.
> @@ -3332,11 +3332,11 @@ To allow for backtrackable destructive updates --- that is, updates
> whose effect is undone on backtracking, perhaps by recording the
> overwritten values on a ``trail'' so that they can be restored
> after backtracking --- Mercury also provides ``mostly unique''
> -modes. The insts @code{mostly_unique} and @code{mostly_dead}
> -are equivalent to @code{unique} and @code{dead},
> +modes. The insts @code{mostly_unique} and @code{mostly_clobbered}
> +are equivalent to @code{unique} and @code{clobbered},
> except that only references which will be encountered during
> forward execution are counted --- it is OK for @code{mostly_unique} or
> - at code{mostly_dead} values to be needed again on backtracking.
> + at code{mostly_clobbered} values to be needed again on backtracking.
>
> Mercury defines some standard modes for manipulating ``mostly unique''
> values, just as it does for unique values:
> @@ -3349,7 +3349,7 @@ values, just as it does for unique values:
> :- mode mui == mostly_unique >> mostly_unique.
>
> % mostly destructive input
> -:- mode mdi == mostly_unique >> mostly_dead.
> +:- mode mdi == mostly_unique >> mostly_clobbered.
> @end example
>
> @node Limitations of the current implementation
> @@ -3363,7 +3363,7 @@ to get a unique field of a unique data structure.
> It is also not possible to use unique-input modes;
> only destructive-input and unique-output modes work.
>
> -The Mercury compiler does not (yet) reuse @code{dead}
> +The Mercury compiler does not (yet) reuse @code{clobbered}
> values. The only destructive update in the current implementation occurs
> in library modules, e.g.@: for I/O and arrays. We do however plan to
> implement structure reuse and compile-time garbage collection
> @@ -5188,9 +5188,8 @@ have any type class constraints.
> The inst @var{varinst} is not allowed to contain any inst variables.
> It is also not allowed to be equivalent to, or contain components that
> are equivalent to, the builtin insts @code{free},
> - at code{unique}, @code{mostly_unique},
> - at code{dead} (@code{clobbered})
> -or @code{mostly_dead} (@code{mostly_clobbered}).
> + at code{unique}, @code{mostly_unique}, @code{clobbered}
> +or @code{mostly_clobbered}.
>
> The initial value of a mutable, @var{initial_value}, may be any Mercury
> expression with type @var{vartype} and inst @var{varinst} subject to
> --
> 2.9.0
>
> _______________________________________________
> reviews mailing list
> reviews at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/reviews
More information about the reviews
mailing list