[m-rev.] for review: check module qualification when testing for type_info

[David Overton]

I'll check in the change with the following changes to the log message
and comments:

--- log.old	Wed Aug 22 17:19:39 2001
+++ log	Fri Aug 24 11:32:00 2001
@@ -4,5 +4,12 @@
 Branches: main
 
 compiler/type_util.m:
-	When testing for type_info types, check that the type is either
-	unqualified or qualified as 'private_builtin'.
+	When testing for type_info types, check that the type is in
+	the 'private_builtin' module.  This allows user-defined types
+	to use the names 'type_info', 'type_ctor_info', etc.
+	
+	This change is required to allow the new module
+	rtti_implementation.m to compile in reserved_tag grades.  The
+	compiler was assuming that the types in this module were the
+	builtin type_info types and was not using the reserved_tag
+	representation for them.
--- mercury/compiler/type_util.m.bak	Wed Aug 22 17:22:38 2001
+++ mercury/compiler/type_util.m	Fri Aug 24 11:23:19 2001
@@ -1032,9 +1032,9 @@
 
 	% If the sym_name is in the private_builtin module, unqualify it,
 	% otherwise fail.
-	% A sym_name is in private_builtin iff it is unqualified or it is
-	% qualified with the private_builtin module.
-
+	% All, user-defined types should be module-qualified by the
+	% time this predicate is called, so we assume that any
+	% unqualified names are in private_builtin.
 :- pred unqualify_private_builtin(sym_name, string).
 :- mode unqualify_private_builtin(in, out) is semidet.
 

On Thu, Aug 23, 2001 at 11:39:52AM +0200, Tyson Dowd wrote:
> On 23-Aug-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > On 23-Aug-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > I'm not sure what "not compilable" means?  Does it mean the compiler
> > > falls over because it assumes that any type with the name "type_info" is
> > > private_builtin__type_info?
> > 
> > I expect so. The compiler does have special handling of type constructors
> > named "type_info", because unlike other type constructors, they (and the tuple
> > type constructor) take a variable number of arguments.
> 
> For the record, the higher order type constructor is treated specially
> too.
> 
> > 
> > > If so isn't this just a plain old bug --
> > > the user is allowed to have a type called type_info.
> > 
> > I agree, but this change should fix that bug. User-defined type names should
> > have been module-qualified by the time the code in question is executed,
> > and the module name "private_builtin" *is* reserved.
> 
> Sorry, I didn't meant to indicate any doubt about that, I think this is
> the right change, I just wasn't sure from the comment and the log
> message what the intention was.
> 
> > We could insist on the type constructor always being module-qualified with the
> > module private_builtin, but that may require changing polymorphism and any
> > other part of the compiler that introduces typeinfos.
> > 
> > I think the change is fine, except the comment should explain this
> > compiler-phase dependence on the procedure that was fixed.
> 
> This is a good idea.
> 
> > We should also think about whether that procedure should insist on the tuple
> > type having a particular qualification.
> 
> I think this is probably the right approach.
> 
> Tyson.
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------

-- 
David Overton      Department of Computer Science & Software Engineering
PhD Student        The University of Melbourne, Victoria 3010, Australia
+61 3 8344 9159    http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------