[m-rev.] For review: Preparations for mode inference

[Richard Fothergill]

On 2/10/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
>
> > Chiefly isolating nondeterministic behaviour in constraints based
> > mode ordering, so that when mode analysis for a single predicate
> > fails it is dealt with instead of being backtracked out of.
>
> How is it dealt with?
>
> > Make preparations for mode inference.
>
> I suggest rewording that something like the following:
>
>         Isolate the nondeterminism in constraint based mode ordering
>         so that when the analysis of a single predicate fails ...
>
>         Further work towards constraint based mode inference.
>

Changed text reads:

Isolate the nondeterminism in constraint based mode ordering so
that when the analysis of a single predicate fails it is dealt
with straight away (by storing a simple record of the failure,
to be used for error messages).
Further work towards constraint based mode inference.


> compiler/abstract_mode_constraints.m:
> compiler/build_mode_constraints.m:
>         Store PredIds for called predicates that require mode inference
>         with the constraints for the predicate calls.
>
> If the same log message applies to multiple files just group them
> together as above.
>
> ...
>
> > compiler/mode_constraints.m:
> >       No longer need to deal with nondeterministic behaviour of
> >       mode reordering here.
>
>
> Or as it would be more commonly expressed in log messages:
>
>         Minor changes to conform to the above.
>

Appropriate changes made.

>
> > compiler/ordering_mode_constraints.m:
> >       Much nondeterministic and committed choice behaviour moved.
> >       A simple data structure documenting any failure in mode
> >       analysis introduced. Variables renamed to conform with
> >       current conventions (s/PredID/PredId/)
>
>
>         Conform to the above changes.
>
>         Add a data structure to record reasons for mode analysis
>         failures.
>
>         s/PredID/PredId/
>

Changed text reads:

compiler/ordering_mode_constraints.m:
        Conform to the above changes.
        Add a data structure to record reasons for mode analysis
        failures. Include printing of that structure where failure
        occurs.
        s/PredID/PredId/

> >          pred_constraints    ::  assoc_list(constraint_formula,
> > -                                    constraint_annotation)
> > +                                    constraint_annotation),
> >                                  % Stores constraints that apply to all
> >                                  % procedures of the predicate -
> >                                  % typically generated from its clauses.
>
>
> What do you mean by "typically"?  Is there some atypical way of generating
> the constraints?

At the moment, all such constraints are generated from the clauses. The
full constraint system however contains some solver variables that are not
independent of each other - ie, there will be some constraints relating
them that do not refer to the source code at all (and as such I have,
perhaps unfairly, deemed them 'atypical').

> > +    % add_mode_infer_callee(PredId, !PredConstraints) records in
> > +    % PredConstraints that predicate PredId is called and needs
> > +    % to have modes infered for it to be called in.
>
> s/infered/inferred/

Done (here and throughout).

>
>
> Perhaps, something like:
>
>         % Add PredId to the set of predicates that requires mode inference.
>

Left most of the original intact, but reworded the ungainly parts.

> > +    % A way of returning the manner of mode analysis failure.
> > +    %
> > +:- type mode_analysis_failures == list(mode_analysis_failure).
> > +
> > +    % A way of returning the manner of mode analysis failure.
> > +    %
>
> How about:
>
>         This type stores information about a mode analysis failure.
>         This information is used when producing error messages ....
>

Changed.
> > +        list.foldl2(proc_reordering(PredConstraints, VarMap, PredId), ProcIds,
> > +            [], Errors, PredInfo1, PredInfo),
> > +
> > +        (
> > +            Errors = [],
> > +            module_info_set_pred_info(PredId, PredInfo, !ModuleInfo)
> > +        ;
> > +            Errors = [_ | _],
> > +            % XXX Deal with mode errors here!
> > +            sorry(this_file, "mode checking failure")
> > +        )
>
> Even at this stage it would be useful if some sort of error message were
> printed out.
>

I've altered it to print out the string.string/1 representation of the data
structure at least. This is just a placeholder - more like debugging code -
awaiting the completion of mode inference.
> > +    % solve_proc_reordering is cc_multi because each of its solutions
> > +    % is equivalent in the sense that they all contain the same goals
> > +    % and conjunctions are ordered according to some legitimate
> > +    % solution to the producing and consuming goals of program
>
> I suggest just: producer/consumer
>
> > +    % variables.
> > +    %

I think grammatically it makes more sense as "producing and consuming" - ?
Will commit as is.

>
> That's okay otherwise.
>
> Julien.

Thanks. I'll commit it later today.

-Richard.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------