[m-dev.] Re: construct__get_functor bug

[Fergus Henderson]

On 19-Dec-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> construct__get_functor doesn't work correctly for types which contain
> existentially quantified data (ie std_util:univ/1).
> 
> There are two reasons for this.
> 
> The first is that mercury_construct.c doesn't handle MR_TYPECTOR_REP_UNIV
> in either MR_get_functor_info or MR_get_num_functors.  However placing a
> `case MR_TYPECTOR_REP_UNIV:' in the same switch arm as MR_TYPECTOR_REP_DU
> should solve this problem, if my understanding of the RTTI is correct.

Hmm.  Do we still use MR_TYPECTOR_REP_UNIV?
The `univ' type is just defined as an ordinary existentially quantified
discriminated union type using ordinary Mercury code in std_util.m,
not as a built-in type.  I don't think we use MR_TYPECTOR_REP_UNIV at all
anymore.

> The showstopper is that the call to
> MR_pseudo_type_info_vector_to_type_info_list() from construct:get_functor/6
> and construct:get_functor_2/7.  MR_pseudo_type_info_vector_to_type_info_list()
> then calls MR_create_type_info() which doesn't work for any existentially
> quantified arguments.
> 
> I am not familar enough with the RTTI type system to fix the second problem
> myself, could someone familar with this do it?

Well, I think there is a design problem to address first.
What do you think "correct" results should be for construct__get_functor
on an existentially quantified type?
Note that `type_desc' represents a ground type, not a type whic may have
type variables in it.

Implementing "construct" for existentially quantified types in general
is non-trivial task, especially for the case where the existentially
quantified types are typeclass-constrained.

The simplest thing to do for now would be to modify the documentation
for construct__get_functor to make it clear that it will fail for
existentially quantified types.  Likewise for construct__construct,
although in this case the documentation should only say that
the current implementation will fail for existentially quantified
types -- we don't want to preclude implementations from handling
that case in the future.  For construct__get_functor, I think
handling existential types would require a different interface.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------