[m-rev.] for review by Mark: a note on bug 154

[Mark Brown]

Hi,

On 15-Sep-2010, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> Mark, I would appreciate your opinion on the comment I added to hlds_rtti.m.

I agree with the analysis.  Regarding the possible fixes, what is wrong with
the solution proposed in Mantis?  If an existentially typed value is created
in two separate branches, then it effectively doesn't have the same type in
each one.  So I think the best fix would be to clone the corresponding
information in rtti_varmaps.  Am I missing something?

Cheers,
Mark.


> @@ -423,6 +422,42 @@
>      % type_info for T, since it does not occupy a slot in the typeclass_info
>      % directly, but is inside the type_info for list(T).
>      %
> +    % XXX Even the information that is recorded has the wrong key. Consider
> +    % a conjunction between:
> +    %
> +    % - a call that returns an existentially typed result, and
> +    % - a goal that uses that existentially typed variable.
> +    %
> +    % Let us say that the conjunction looks like
> +    %
> +    %   gen_result(X_1, TypeInfo_for_T_2), use_result(TypeInfo_for_T_2, X_1).
> +    %
> +    % This conjunction can be duplicated, e.g. by switch detection (it could be
> +    % in a switch arm that is guarded by a disjunction that handles different
> +    % values of the switched-on variable differently) or by tabling.
> +    % (This is what happens in Mantis bug #154.)
> +    %
> +    % In such cases, the renamed-apart duplicated goal would be something like
> +    %
> +    %   gen_result(X_3, TypeInfo_for_T_4), use_result(TypeInfo_for_T_4, X_3).
> +    %
> +    % Yet the rtti_var_map for the procedure would say that X_3 is of the same
> +    % type as X_1, which means that the compiler would think that X_1 and X_3
> +    % use the same type_info variable to represent their types. This would be
> +    % TypeInfo_for_T_2, even though it won't exist on the execution branch
> +    % containing the copied version of the goal.
> +    %
> +    % I (zs) can see two possible fixes.
> +    %
> +    % - First, we could have type_info_varmap map each tvar to a nonempty set
> +    %   of type_info_locns, exactly one of which would be available on every
> +    %   execution path. It would be the responsibility of other parts of the
> +    %   compiler to pick the right one.
> +    %
> +    % - Second, instead of mapping prog_vars to types, and the tvars in those
> +    %   types to the prog_vars holding their type_infos, we could map each
> +    %   prog_var directly to a {tvar -> typeinfo progvar} map.
> +    %
>  :- type type_info_varmap == map(tvar, type_info_locn).
>  
>      % Every program variable which holds a type_info is a key in this map.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------