[m-rev.] for review: base_typeclass_info rtti refs

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu May 8 16:05:02 AEST 2003


On 08-May-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > +	--->	rtti_id(rtti_type_ctor, rtti_name)
> > +	;	tc_rtti_id(tc_rtti_name).
> > +
> >  :- type rtti_name
> 
> A comment or two here might help.

I added:

% All rtti_data data structures and all their components are identified
% by an rtti_id. For data structures that are part of the description
% of a single type constructor, we use the rtti_id functor, and make the
% id of that type constructor part of the id of the data structure.
% For data structures that are not necessarily associated with a single type,
% which for the foreseeable future are all associated with typeclasses,
% we use the tc_rtti_id functor.

> Also, I think it would be clear to name the constructor for the
> first alternative as "name_rtti_id".

I am open to alternatives, but name_rtti_id is not an improvement. The
difference that distinguishes things named with rtti_id(TypeCtor, RttiName)
from things named with tc_rtti_id(TcRttiName) is the TypeCtor, not the
RttiName. I am calling that constructor ctor_rtti_id.

> > @@ -521,8 +527,7 @@
> >  	% Convert a rtti_data to a rtti_type_ctor and a rtti_name.
> >  	% This calls error/1 if the argument is a type_var/1 rtti_data,
> >  	% since there is no rtti_type_ctor to return in that case.
> > -:- pred rtti_data_to_name(rtti_data::in, rtti_type_ctor::out, rtti_name::out)
> > -	is det.
> > +:- pred rtti_data_to_id(rtti_data::in, rtti_id::out) is det.
> 
> The comment there about calling error/1 is no longer valid.

Yes, it is. The error is just generated one level further down.
Typeinfo and pseudotypeinfos data structures still have old style names.
The reason why type_var pseudotypeinfos do not need the new,
rtti_type_ctor-less names is that they have no associated data structure.

> It might be clearer to include the comment just once, and group the
> declarations:
> 
> 		% Return true iff the given type of RTTI data structure
> 		% includes code addresses.
> 	:- func rtti_id_would_include_code_addr(rtti_id) = bool.
> 	:- func rtti_name_would_include_code_addr(rtti_name) = bool.
> 	:- func tc_rtti_name_would_include_code_addr(tc_rtti_name) = bool.
> 	:- func type_info_would_incl_code_addr(rtti_type_info) = bool.
> 
> Actually the same goes for the other functions like this.

Done.

> > -		output_addr_of_rtti_addr(RttiTypeCtor, field_types(Ordinal))
> > +		output_addr_of_rtti_addr( RttiTypeCtor, field_types(Ordinal))
> 
> s/( /(/

Done.

> > +output_rtti_addr_storage_type_name(RttiId, BeingDefined) -->
> 
> That should probably be renamed output_rtti_id_storage_type_name.

Done.

> > +output_addr_of_rtti_addr(RttiTypeCtor, RttiName) -->
> > +	output_addr_of_rtti_id(rtti_id(RttiTypeCtor, RttiName)).
> 
> Likewise here the use of rtti_addr is historical and no longer meaningful.
> I suggest renaming this output_addr_of_name_rtti_id.

Done.
> 
> > +output_rtti_addr(RttiTypeCtor, RttiName) -->
> > +	output_rtti_id(rtti_id(RttiTypeCtor, RttiName)).
> 
> Likewise here, I suggest renaming to output_name_rtti_id.

Done.

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



More information about the reviews mailing list