[m-dev.] for review: type_info/X switcheroo.

Tyson Dowd trd at stimpy.cs.mu.oz.au
Mon Aug 3 14:48:49 AEST 1998


On 03-Aug-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 02-Aug-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > Estimated hours taken: 3
> > 
> > Allow private_builtin:type_info/1 to be printed using io__write.
> > 
> > library/io.m:
> > 	Use another horrible hack to find private_builtin:type_info/1
> > 	to be detected and handled as if it were std_util:type_info/0
> > 	for printing.
> > 
> > library/private_builtin.m:
> > 	Add a hand-written type defintion for
> > 	private_builtin:type_info/1.  (Much the same definition that
> > 	was previously used for std_util:type_info/0.
> > 
> > library/std_util.m:
> > 	Define std_util:type_info/0 as an abstract equivalence to
> > 	private_builtin:type_info/1.
> > 	Remove the old type defintions for std_util:type_info/0.
> 
> I'd like to see a test case.

Hmmm.  Difficult.  The problem only really surfaces when garbage collecting
with debugging on.  Only the runtime system has access to anything that
has been assigned the the private_builtin:type_info/1.  The debugger
deliberately avoids printing TypeInfo_for_ variables at the moment.

If you have any ideas for a good test case, let me know.

> 
> > Index: library/io.m
> > ===================================================================
> > RCS file: /home/staff/zs/imp/mercury/library/io.m,v
> > retrieving revision 1.159
> > diff -u -r1.159 io.m
> > --- io.m	1998/07/22 07:41:32	1.159
> > +++ io.m	1998/07/31 00:37:33
> > @@ -1708,6 +1708,12 @@
> >  		io__write_univ_as_univ(OrigUniv)
> >  	; { univ_to_type(Univ, C_Pointer) } ->
> >  		io__write_c_pointer(C_Pointer)
> > +	; { type_ctor_name(type_ctor(univ_type(Univ))) = "type_info" },
> > +	  { type_ctor_module_name(type_ctor(univ_type(Univ))) =
> > +			"private_builtin" } ->
> > +	  	% XXX Horrible hack!
> > +		{ TypeInfo = unsafe_cast(univ_value_as_type_any(Univ)) },
> > +		io__write_string(type_name(TypeInfo))
> 
> It would be better if the comment explained why that hack was
> necessary, rather than just exclaiming about how horrible it is.

I've changed it to 
                % XXX This is a hack (see the comment for array below).

about 3 lines below this the comment for array says:

		 % Note that we can't use univ_to_type above, because we
		 % want to match on a non-ground type `array(T)'
		 % (matching against `array(void)' isn't much use).
		 % Instead, we explicitly check the type name.  That
		 % makes it tricky to get the value, so we can't use
		 % io__write_array below...  instead we use the
		 % following, which is a bit of a hack.

> > +	% XXX These two functions and the type definition 
> > +	% are just temporary, they are used for the
> > +	% horrible hack above.
> 
> If they are temporary, what is the planned replacement?
> 

Actually, I was hoping you could help me out there ;-)  You said you were
going to post some code you wrote a while ago that improves the
situation using existential types.  That code is the planned replacement
for this hack.  I would describe it here if I had seen it.

> > +/* Ensure that the initialization code for the above module gets run. */
> > +/*
> > +INIT sys_init_type_info_module
> > +*/
> > +extern ModuleFunc unify_univ_module;
> > +void sys_init_type_info_module(void); /* suppress gcc -Wmissing-decl warning */
> > +void sys_init_type_info_module(void) {
> > +	extern ModuleFunc type_info_module;
> > +	type_info_module();
> > +}
> 
> Please don't use nested extern declarations.
> 
> Why is the declaration for `unify_univ_module' there?

Ooops, cut and paste error.  Sorry.

-- 
       Tyson Dowd           # "Bill Gates is a white persian cat and a monocle
                            # away from becoming another James Bond villan."
     trd at cs.mu.oz.au        # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd #                -- Dennis Miller and Terri Branch



More information about the developers mailing list