[m-dev.] for review: add support for existential types [1/4]

[David Glen JEFFERY]

[In reply to fjh's comments for part 1].

I'm happy with the way you've addressed my comments for this part. Here's a
couple of comments, though:

> On the other hand, it really ought to be documented _somewhere_ in the
> intervening period.  Perhaps we should a new section to the language
> reference manual for "Future extensions" which would be less stable.

That's probably a good idea, but not necessary for this commit.

> > > +++ inlining.m	1998/06/29 09:25:38
> > 
> > > @@ -315,6 +317,11 @@
> > >  		int,			% variable threshold for inlining
> > >  		set(pred_proc_id),	% inlined procs
> > >  		module_info,		% module_info
> > > +		list(tvar),		% universally quantified type vars
> > > +					% occurring in the argument types
> > > +					% for this predicate (the caller,
> > > +					% not the callee).  These are the
> > > +					% ones that must not be bound.
> > 
> > Does this include the existential tvars from the callees too?
> 
> This is a good question.  No, it doesn't.
> 
> The reason it doesn't is that it may need to bind type variables
> for a callee, if it is inlining that callee.
> 
> The only time that binding type variables causes a problem
> is if we bind one of the universally quantified type vars
> in the argument types for the predicate.  Such bindings
> could only ever rename the type variable to something different,
> rather than actually binding it to a ground type, but that
> might cause problems because, um, the list of type variables
> in the pred decl would no longer be the same as the type variables
> in the proc.  Well, I'm not sure if that would cause problems,
> but I'm not sure it won't, so best to be on the safe side.
> 
> So how about I just add "... must not be bound, because renaming
> those type variables would mean that the type variables in the
> proc_info don't match the ones in the pred_info, which I think
> might cause problems." at the end of that comment?

That will be fine. Please do so.

> +% not bind any of the non-local variables such as `X' in the above
> +% example.
>  %
> -%	Note: Support for lambda expressions which involve class constraints
> -%	      is not yet complete.
> +% Similarly, a lambda expression not bind any of the type_infos for

s/expression not/expression may not/


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.