[m-dev.] for review: type specialisation [2]

[Simon Taylor]

 mercury_to_mercury.m:
> This change (to include variable numbers in the output types)
> was not listed in the log message.
> 
> I think this change is a good idea in the long term
> but in the short term it may cause some inconsistency, because
> there are other places which print types without the variable numbers.

I'll go through and fix that as a separate change.

> Hmm, that's a worry.  Should we be disabling --deforestation if
> --typeinfo-liveness is specified?

We already do. It should be pretty simple to fix.

> 
> type_util.m:

> > -                % find the new var, if there is one
> > -        ( map__search(Subst, Var, NewVar0) ->
> > -                NewVar = NewVar0
> > +        ( map__search(TSubst, NewTVar2, NewType0) ->
> > +                NewType = NewType0
> >          ;
> > -                NewVar = Var
> > +                % The variable wasn't substituted.
> > +                type_util__var(NewType, NewTVar2)
> >          ),
> > -        type_info_locn_set_var(Locn, NewVar, NewLocn),
> 
> Should it apply TSubst recursively here?

Definitely. Make that:
+        term__apply_rec_substitution(term__variable(NewTVar2),
+                TSubst, NewType),
+

> doc/user_guide.texi:
> > + at sp 1
> > + at item --higher-order-size-limit
> > +Set the maximum goal size of specialized versions created by
> > + at samp{--optimize-higher-order} and @samp{--type-specialization}.
> 
> It would be helpful to give some indication of the units
> (both here and in the help message in options.m).

I've added (in both places):
+ Goal size is measured as the number of calls, unifications
+ and branched goals.

> 
> > @@ -97,6 +98,9 @@
> >  # some tests need to be compiled with particular options
> >  
> >  MCFLAGS-boyer           =       --infer-all
> > +MCFLAGS-cut_test        =       -O5
> 
> cut_test.m will get tested at -O5 on murlibobo anyway;
> is there a particular reason why it is better to test it at -O5
> on all architectures rather than testing it at different optimization
> levels on the different machines?

It caused problems with value numbering (according to the nightly test log
it still does). Zoltan added a separate test case for that problem, so yes,
this should be removed.

Thanks Fergus.

Simon.