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

[Peter Ross]

On Fri, Nov 21, 2003 at 02:10:04PM +1100, Fergus Henderson wrote:
> On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > Index: compiler/make_hlds.m
> > ===================================================================
> > RCS file: /home/mercury1/repository/mercury/compiler/make_hlds.m,v
> > retrieving revision 1.452
> > diff -u -r1.452 make_hlds.m
> > --- compiler/make_hlds.m	20 Nov 2003 11:35:40 -0000	1.452
> > +++ compiler/make_hlds.m	20 Nov 2003 21:21:42 -0000
> > @@ -161,11 +161,30 @@
> >  		InvalidTypes1 = no,
> >  		module_info_types(Module2, Types),
> >  		map__foldl3(process_type_defn, Types,
> > -			no, InvalidTypes2, Module2, Module3, !IO)
> > +			no, InvalidTypes2, Module2, Module3a, !IO)
> 
> The time when you start introducing names like "Module3a" is the time to
> switch to state variable notation.  So IMHO this is OK for the purpose
> of this patch if and only if it is followed by a patch to change this
> procedure to use state variable notation.
> 
> Note that the way to introduce a state variable notation
> for a local variable sequence is to use an explicit quanitifer:
> 
> 	some [!Module] (
> 		... code using !.Module, !:Module, and !Module ...
> 	]
> 
Thanks, I was wondering how you did that!

> > +		;
> > +		    map__lookup(TypeTable, TypeCtor, TypeDefn),
> > +		    hlds_data__get_type_defn_body(TypeDefn, TypeBody),
> > +		    (
> > +			TypeBody \= abstract_type(_)
> > +		    ->
> > +			\+ type_ctor_has_hand_defined_rtti(TypeCtor, TypeBody),
> > +			( are_equivalence_types_expanded(ModuleInfo)
> > +				=> TypeBody \= eqv_type(_) )
> > +		    ;
> > +			% type_ctor_infos need be generated for the builtin
> > +			% types (which are declared as abstract types)
> > +			compiler_generated_rtti_for_the_builtins(ModuleInfo),
> > +			TypeModuleName = unqualified(ModuleNameString),
> > +			( builtin_type_ctor(ModuleNameString,
> >  					TypeName, TypeArity, _)
> > +			; impl_type_ctor(ModuleNameString,
> >  					TypeName, TypeArity, _)
> >  			)
> > +		    )
> >  		)
> 
> This code is very unclear now.  Didn't it already check for
> builtin_type_ctors above?  What is the difference between
> calling builtin_type_ctor/4, and checking membership of
> the list returned by builtin_type_ctors?
> 
The problem is the call to map__lookup(TypeTable, TypeCtor, TypeDefn)
which will fail if you are looking for a builtin type, as we no longer
have a type_defn generated for it.

I will address the rest of the review comments on monday.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------