[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