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

[Fergus Henderson]

On 23-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> On Sun, Nov 23, 2003 at 10:53:06PM +1100, Fergus Henderson wrote:
> > On 21-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > compiler/type_util.m:
> > > 	s/builtin_type_ctors/builtin_type_ctors_with_no_type_defn/
> > > 	which better reflects which type ctors this function returns.
> > > 
> > > compiler/type_ctor_info.m:
> > > 	Improve the documentation of how the code determines whether
> > > 	or not a type_ctor_info needs to be generated.
> > > 
> > > compiler/typecheck.m:
> > > 	Use builtin_type_ctors_with_no_type_defn and make the documentation
> > > 	more explicit.
> > 
> > > Index: compiler/type_ctor_info.m
> > > @@ -114,26 +114,28 @@
> > >  		ModuleName, ModuleInfo, TypeCtorGenInfos1),
> > >  	TypeCtor = SymName - TypeArity,
> > >  	(
> > > +	    % Check if we should generate a type_ctor_info for this type.
> > > +	    % There are three cases that we have to check
> > > +	    % 	- the builtin types which have no type defn
> > > +	    % 	- the builtin types which are declared abstract
> > > +	    % 	- all the rest of the types
> > 
> > Huh?  What's the difference between the first two cases?
> > 
> > Did you mean to say "no type declaration" instead of "no type defn"?
>
> Quite often we have code in the compiler
> 
>     module_info_types(ModuleInfo, TypeTable),
>     map__lookup(TypeTable, TypeCtor, TypeDefn)
> 
> The first case is where this lookup will throw an exception because
> there is no "type definition", the second case is where this will return
> a "type definition" which type body is abstract.
> 
> Does this help?

It helps me understand.  But the source code should be understandable
without the reader having to refer back to the archives of the
mercury-reviews mailing list ;-)

> Maybe s/type defn/hlds_type_defn/ ?

That would help, yes.

But it would be even better to also explain what this means.
E.g.

	% There are three cases that we have to check
	%
	% 	- the builtin types which have no hlds_type_defn
	%	  (i.e. no declaration and no definition)
	%
	% 	- the builtin types which are declared abstract
	%	  and are not defined
	%	  (i.e. they have a declaration, but no definition)
	%
	% 	- all the rest of the types
	%	  (types with a definition, or both a declaration
	%	  and a definition)

> > > Index: compiler/type_util.m
> > ...
> > > +	% The list of type_ctors which are builtins which do not have a
> > > +	% hlds_type_defn, ie. those builtin type which are not declared as
> > > +	% abstract types in the standard library.
> > > +:- func builtin_type_ctors_with_no_type_defn = list(type_ctor).
> > 
> > The comment here seems wrong, since e.g. array/1 is declared as an
> > abstract type in the standard library, but is not included in this list.
> > 
> The key word you have missed is not.
>     ie those builtin type which are **NOT** declared as abstract types in
>     the standard library.

Sorry, my mistake.

But the comment is still wrong, since it does not take into account the
cae of builtin types which are defined as concrete types in the standard
library, such as e.g. builtin.comparison_result.

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