[m-dev.] for review: add support for existential types [1/4]
David Glen JEFFERY
dgj at cs.mu.OZ.AU
Tue Jul 7 12:32:27 AEST 1998
[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,
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