[m-rev.] for post-commit review: centralize decisions about mutables' aux preds
Julien Fischer
jfischer at opturion.com
Mon Sep 2 11:52:13 AEST 2019
Hi Zoltan,
On Sun, 1 Sep 2019, Zoltan Somogyi wrote:
> Centralize decisions about which aux preds a mutable needs.
...
> diff --git a/compiler/add_pred.m b/compiler/add_pred.m
> index 35f1b08dd..67f139ea4 100644
> --- a/compiler/add_pred.m
> +++ b/compiler/add_pred.m
...
> diff --git a/compiler/prog_data.m b/compiler/prog_data.m
> index a2274fdc7..57b1de132 100644
> --- a/compiler/prog_data.m
> +++ b/compiler/prog_data.m
> @@ -1461,15 +1461,50 @@ best_purity(purity_impure, purity_impure) = purity_impure.
>
> :- interface.
>
> + % The kinds of auxiliary predicates we may need to generate
> + % to implement a mutable.
> + %
> + % The first group represent the public predicates, the predicates
> + % that user programs may call. The usual (non-constant) kind of mutable
> + % will have the standard get and set predicates, and if attached
> + % to the I/O state, will have the I/O get and set predicates as well.
> + % Constant mutables will have the constant get and set predicates instead
> + % (see below).
> + %
> + % The first group represent the private predicates, the predicates
s/first/second/ there.
> + % that user programs should not call (and which are not documented).
> + % The unsafe get and set predicates may be needed to implement the other,
s/may/are/
> + % user-visible get and set predicates, and the lock and unlock predicates
> + % have the same role. The initialization predicate is called by the
> + % implementation itself at program startup, and it may need the help
> + % of the preinit predicate.
...
> diff --git a/library/set.m b/library/set.m
> index 27041df64..5df901712 100644
> --- a/library/set.m
> +++ b/library/set.m
> @@ -150,14 +150,20 @@
> % containing only `X', i.e. if `Set' is the set which contains
> % all the elements of `Set0' except `X'.
> %
> + % The det_remove version aborts if the removal fails.
We generally don't describe library predicates as aborting anymore.
For one thing it's ambiguous: does it throw an exception or do something
else (e.g. call MR_fatal_error)?
I would reword that as as:
The det_version throws an exception instaed of failing.
> + %
> :- pred remove(T::in, set(T)::in, set(T)::out) is semidet.
> +:- pred det_remove(T::in, set(T)::in, set(T)::out) is det.
>
> % `remove_list(Xs, Set0, Set)' is true iff `Xs' does not
> % contain any duplicates, `Set0' contains every member of `Xs',
> % and `Set' is the relative complement of `Set0' and the set
> % containing only the members of `Xs'.
> %
> + % The det_remove_list version aborts if any removal fails.
> + %
Ditto.
The rest looks fine.
Julien.
More information about the reviews
mailing list