[m-dev.] Re: construct__get_functor bug

Peter Ross pro at missioncriticalit.com
Fri Dec 20 02:58:53 AEDT 2002


On Fri, Dec 20, 2002 at 12:50:01AM +1100, Fergus Henderson wrote:
> On 19-Dec-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> > 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 which may have
> type variables in it.
> 
You would need to supply an alternate version of get_functor which would
have an extra argument which would be the actual value from which the
`type_desc' was obtained from.  In fact it would be better to just pass
the value and then obtain the `type_desc' inside the implementation.
This new version wouldn't fail for existentially quantified types.

> Implementing "construct" for existentially quantified types in general
> is non-trivial task, especially for the case where the existentially
> quantified types are typeclass-constrained.
> 
How good is the RTTI for reflection over typeclasses?  My impression is
that we don't have any RTTI for that, only RTTI for dispatching methods.

> 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.
> 
Not only modify the documentation but also the code which currently
causes a seg fault.  I will look into it.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list