[m-rev.] for review: automatically generate all type_ctor_infos on non C backends

[Simon Taylor]

On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> On Thu, Nov 20, 2003 at 10:38:07PM +1100, Simon Taylor wrote:
> > On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > On Thu, Nov 20, 2003 at 01:40:44PM +1100, Fergus Henderson wrote:
> > > > On 19-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > > > Get the compiler to generate the type_ctor_infos for all the types
> > > > > which were previously defined by hand.
> > > > > 
> > > > > This change completes the removal of all the MC++ from the compiler.
> > > > 
> > > > Good stuff, Pete.  Thanks!
> > > > 
> > > > > Index: compiler/special_pred.m
> > > > ...
> > > > >  can_generate_special_pred_clauses_for_type(ModuleInfo, TypeCtor, Body) :-
> > > > > -	Body \= abstract_type(_),
> > > > > +	(
> > > > > +		Body \= abstract_type(_)
> > > > > +	;
> > > > > +		% Only the types which have a unification defined in
> > > > > +		% private_builtin.m
> > > > > +		compiler_generated_rtti_for_the_builtins(ModuleInfo),
> > > > > +		Builtin = mercury_public_builtin_module,
> > > > > +		( TypeCtor = qualified(Builtin, "int") - 0
> > > > > +		; TypeCtor = qualified(Builtin, "string") - 0
> > > > > +		; TypeCtor = qualified(Builtin, "character") - 0
> > > > > +		; TypeCtor = qualified(Builtin, "float") - 0
> > > > > +		; TypeCtor = qualified(Builtin, "pred") - 0
> > > > > +		)
> > > > 
> > > > XXX There should be a comment in private_builtin.m pointing to this code.
> > > > XXX Treating pred/0 specially here seems odd and possibly wrong;
> > > >     what about func/0, pred/1, etc.?

The lack of a case for builtin.func/0 is suspicious,
but builtin.pred/1 does not exist.

> > > pred/0 is treated specially here because it has a unification procedure
> > > defined in private_builtin.m, while pred/1 and func/0 don't.  Maybe the
> > > definition of private_builtin.builtin_unify_pred should mention pred/1
> > > instead?

> > I'm pretty sure your code here is wrong.
> > There is one MR_TypeCtorInfo (and hence unification predicate) for each
> > of pred/N, func/N and {}/N.
> >  
> It isn't wrong, there is always a unification predicate generated but is
> that predicate generated by unify_proc or defined out-of-line in C#?
> 
> This bit of code tests is there an implementation in Mercury for the
> unification and comparison predicates for these types?
> 
> As there is no private_builtin.builtin_unify_func the Mercury compiler
> generates a call to mercury.builtin.special__Unify__func_0_0 which then
> calls mercury.builtin.special__Unify__func_0_0, where this deep magic
> occurs I am not sure.
> 
> However there is a mercury predicate builtin_unify_pred which unifies
> pred so in that case we generate for the Unify predicate for pred/0
> (maybe the name is wrong, but that is what we had before in the code)
> which simply calls private_builtin.builtin_unify_pred.
> 
> Look in add_special_preds in make_hlds.m to see the two different cases
> for adding the special_pred explained above.
> 
> Does this help?

It suggests that your code works in non-obvious ways. 
The lack of a case for `tuple' in the switch on TypeCtor is also
suspicious.  The RTTI for pred/0, func/0 and tuple/0 should all be
implemented the same way.

I think the use of "abstract" definitions of the builtin types 
to force generation of RTTI is a bit of a kludge (for a start,
the type name should be `int', not `builtin.int').  It would be
better to handle the builtin types explicitly as a special case
in make_hlds.m.

> > > > Please add some comments here.
> > > > 
> > > > I don't understand why we need to special-case "ticket";
> > > > that looks like it might be a bug.
> > > > 
> > > It is to do with the fact that ticket is defined as having an
> > > impl_type_ctor but it's definition is
> > > 
> > > :- type ticket == c_pointer.
> > > 
> > > What I have done is change the code to the following, which means that
> > > we only generate type_ctor_infos for the builtin types which are
> > > abstract.
> > 
> > Would making `ticket' a foreign type rather than an equivalence remove
> > some of the special casing?
> >  
> The snipped code that you deleted fixes the problem.
> 
> However the best solution in the long run would be to make everything
> builtin a foreign_type.  This would require adding a new annotation to
> the foreign_type which declared that there was only one representation
> for equal types to avoid the problems mentioned in the User Manual
> <http://tinyurl.com/vte6>.

OK, that's a separate issue.

Simon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------