[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