[m-dev.] for review: type specialisation [2]
David Glen JEFFERY
dgj at cs.mu.OZ.AU
Wed Sep 2 18:49:54 AEST 1998
On 02-Sep-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 30-Aug-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> >
> > +++ hlds_data.m 1998/08/12 04:19:21
> > @@ -36,12 +36,14 @@
> > % whereas a code_addr_const is just an address.
> > ; base_type_info_const(module_name, string, int)
> > % module name, type name, type arity
> > + ; base_typeclass_info_const(module_name,
> > + class_id, int, string)
> > % name of module containing instance
> > + % declaration (not filled in by
> > + % polymorphism.m - why?), class name and arity,
> > + % class instance, a string encoding the type
> > + % names and arities of the arguments to the
> > + % instance declaration
>
> Anyone know why the module_name in a base_typeclass_info_const
> is not filled in by polymorphism.m? DJ?
The code which creates base_typeclass_info_consts in polymorphism.m has this
in front of it:
% XXX I don't think we actually need to carry the module name
% around.
ModuleName = unqualified("some bogus module name"),
The reason is that, when the base_typeclass_info_const is output, the module
name is not included so that we at least get a link error for overlapping
instances in separate modules.
The problem is that the way the representation works in the code generator,
each data_addr_const must have an associated module... so we need to store
something somewhere. Maybe it would be best to get rid of this field, and
fill in a junk module name when the code generator makes the data_addr_const
in unify_gen.m. (?)
love and cuddles,
dgj
--
David Jeffery (dgj at cs.mu.oz.au) | Marge: Did you just call everyone "chicken"?
PhD student, | Homer: Noooo. I swear on this Bible!
Department of Computer Science | Marge: That's not a Bible; that's a book of
University of Melbourne | carpet samples!
Australia | Homer: Ooooh... Fuzzy.
More information about the developers
mailing list