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

[Fergus Henderson]

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.?
> > 
> 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 think builtin_unify_pred is used for _all_ higher-order unifications,
regardless of whether they are functions or predicates,
and regardless of the arity.

For the type_ctor_infos, I think there should be a type_ctor_info for
predicates and one for functions.  But only one of each, not one for
each arity.

> > What sort of testing of the il grade have you done to ensure that
> > this change didn't break things?
>
> Run "hello, world".  Believe it or not a good test because of all the
> stuff that goes on in the background initialising the mercury runtime.
> I have also run all the tests in hard_coded/typeclasses plus some of the
> tests which have the word unify in their name.

OK, that seems reasonable then.

> > Otherwise, this change looks fine.
>
> Thanks but I have found a problem when bootstrapping under linux in
> asm_fast.gc (the problem doesn't appear in windows).  However simply
> commenting out the new abstract type definitions in builtin.m stops the
> bug being triggered, but of course breaks the compilation of the il
> grade.
> 
> The approach I have decided to take is to comment out the offending
> definitions and check it in.  Then I will fix the problem under linux as
> a seperate change.

Generally it's better to break the il grade than the Linux asm_fast.gc
grade... currently a lot more people are relying on the latter!

Of course it is even better to not break things at all.
Ideally it should all be steps forward, not two steps forward one step back.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------