[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