[m-rev.] for post-commit review: don't create redundant type_infos

[Mark Brown]

Hi,

On 14-Sep-2009, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> For review by Mark. Could someone from G12 (a) measure the effect this has
> on the code that was the motivation for this change, and (b) tell me if
> the same thing needs to be done for the creation of redundant typeclass_infos.

The change is fine, apart from a couple of comments below.  I'll do (a)
shortly and let you know; I expect the answer to (b) will be yes, but I'll
take a look at the hlds dumps from (a) and see.

> +        ;
> +            TermVarTypeVars = [],
> +            % TermVarTypeVars = [] says that there is no polymorphism imposed
> +            % from the outside via TermVar, and MaxVarAfter = MaxVarBefore
> +            % and NumReusesAfter = NumReusesBefore together say that there was
> +            % no polymorphism added by the goals inside the scope (since those
> +            % would have required the creation or reuse of typeinfo variables).
> +            % XXX zs: I am only 90% sure of the statement in the parentheses.
> +            % If it turns out to be wrong, we would have to add a flag to
> +            % poly_infos that is set whenever this pass modifies a goal,
> +            % at least in ways that would invalidate the
> +            % from_ground_term_construct invariant.
> +            Reason = from_ground_term(TermVar, from_ground_term_construct),
> +            SubGoal = SubGoal1
> +        )
> +    ;
> +        % We did introduced some variables into the scope, so we cannot

s/introduced/introduce/

or remove 'did'

> @@ -2104,12 +2223,13 @@
>      % or the arguments of existentially typed predicate calls, function calls
>      % and deconstruction unifications.
>      %
> -    % Type(class)-infos for ground types added to predicate calls, function
> -    % calls and existentially typed construction unifications do not require
> -    % requantification because they are local to the conjunction containing
> -    % the type(class)-info construction and the goal which uses the
> +    % Type(class)-infos added for ground types added to predicate calls,

This makes less sense than before.  Should the second 'added' be 'passed'?

> @@ -3451,6 +3605,9 @@
>                  % Specifies the constraints at each location in the goal.
>                  poly_constraint_map     :: constraint_map,
>  
> +                poly_type_info_var_map  :: type_info_var_map,
> +                poly_num_reuses         :: int,
> +

You should document these fields.  In particular, that the map only contains
some but not all type_infos that are available (i.e., it's for optimisation).

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------