[m-dev.] for review: MR_TypeInfo cleanup, part 3 (of 3)

[Tyson Dowd]

On 22-Mar-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> Index: runtime/mercury_type_info.c
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_type_info.c,v
> retrieving revision 1.33
> diff -u -b -r1.33 mercury_type_info.c
> --- runtime/mercury_type_info.c	2000/03/10 13:38:15	1.33
> +++ runtime/mercury_type_info.c	2000/03/22 06:39:41
> @@ -15,234 +15,81 @@
>  
>  /*---------------------------------------------------------------------------*/
>  
> -static Word *
> -MR_get_arg_type_info(const Word *term_type_info, 
> -	const Word *arg_pseudo_type_info, const Word *data_value, 
> -	int rtti_version, const MR_DuFunctorDesc *functor_desc);
> +static MR_TypeInfo
> +MR_get_arg_type_info(const MR_TypeInfoParams type_info_params, 
> +	const MR_PseudoTypeInfo pseudo_type_info, const Word *data_value, 
> +	const MR_DuFunctorDesc *functor_desc);
>  
>  /*---------------------------------------------------------------------------*/
>  
>  extern	struct MR_TypeCtorInfo_struct	mercury_data___type_ctor_info_pred_0;
>  extern	struct MR_TypeCtorInfo_struct	mercury_data___type_ctor_info_func_0;
>  
> -	/* 
> -	** MR_create_type_info():
> -	**
> -	** Given a type_info `term_type_info' which contains a
> -	** type_ctor_info pointer and possibly other type_infos
> -	** giving the values of the type parameters of this type,
> -	** and given a pseudo-type_info `arg_pseudo_type_info', which contains
> -	** a type_ctor_info pointer and possibly other type_infos
> -	** giving EITHER
> -	** 	- the values of the type parameters of this type
> -	** or	- an indication of the type parameter of the
> -	** 	  term_type_info that should be substituted here,
> -	** this returns a fully instantiated type_info, a version of the
> -	** arg_pseudo_type_info with all the type variables filled in.
> -	**
> -	** We allocate memory for a new type_info on the Mercury heap,
> -	** copy the necessary information, and return a pointer to the
> -	** new type_info.  You need to wrap save_transient_hp()
> -	** and restore_transient_hp() around calls to this function.
> -	**
> -	** In the case where the argument's pseudo_type_info is a
> -	** type_ctor_info with no arguments, we don't copy the
> -	** type_ctor_info - we just return a pointer to it - no memory
> -	** is allocated. The caller can check this by looking at the
> -	** first cell of the returned pointer - if it is zero, this is a
> -	** type_ctor_info. Otherwise, it is an allocated copy of a
> -	** type_info.
> -	**
> -	** If arg_pseudo_type_info does not contain any type variables,
> -	** then it is OK for term_type_info to be NULL.
> -	**
> -	** NOTE: If you are changing this code, you might also need
> -	** to change the code in MR_make_type_info in this module 
> -	** which does much the same thing, only allocating using MR_GC_malloc()
> -	** instead of on the Mercury heap.
> -	**
> -	** The rtti version number we pass in the call below is a placeholder;
> -	** its value does not matter because the functor_desc we pass, whose
> -	** format it describes, is NULL.
> -	*/
> -
> -Word * 
> -MR_create_type_info(const Word *term_type_info, const Word *arg_pseudo_type_info)
> -{
> -	return MR_create_type_info_maybe_existq(term_type_info, 
> -		arg_pseudo_type_info, NULL,
> -		MR_RTTI_VERSION__CLEAN_LAYOUT, NULL);
> -}
> -
> -	/*
> -	** MR_create_type_info_maybe_existq():
> -	**
> -	** The same as MR_create_type_info except that the type-info being
> -	** created may be for an existentially typed argument of a constructor.
> -	** In order to handle this, it also takes the data value from which
> -	** the values whose pseudo type-info we are looking at was taken, as
> -	** well as the functor descriptor for that functor.
> -	**
> -	** If the term_type_info has a NULL type_ctor_info,
> -	** or if the arg_pseudo_type_info does not contain any
> -	** existentially typed type variables, then it is OK
> -	** for the data_value and functor_desc to be NULL.
> -	**
> -	** XXX The rtti_version argument is only temporary; it should not be
> -	** needed once we have bootstrapped the CLEAN_LAYOUT change and
> -	** dropped support for older type_ctor_info versions.
> -	*/
> -
> -Word * 
> -MR_create_type_info_maybe_existq(const Word *term_type_info, 
> -	const Word *arg_pseudo_type_info, const Word *data_value, 
> -	int rtti_version, const MR_DuFunctorDesc *functor_desc)
> +#define	usual_func		MR_make_type_info
> +#define	exist_func		MR_make_type_info_maybe_existq
> +#define	exist_func_string	"MR_make_type_info_maybe_existq"
> +#define	MAYBE_DECLARE_ALLOC_ARG	, MR_MemoryList *allocated
> +#define	MAYBE_PASS_ALLOC_ARG	, allocated

I would find "yes" and "no" as perhaps better values for the last two,
then the code can do this by itself (using #ifdefs).  
This makes the little language you are defining here simpler.
(If there were 3 possible values for this #define then this would
probably be OK).

> +/* 
> +** MR_create_type and MR_make_type_info both turn a pseudo typeinfo into
> +** a typeinfo, looking up the typeinfos associated with the type variables
> +** in the pseudointo typeinfo in the supplied vector of type parameters.
> +**
> +** The two functions differ in how they allocate memory. MR_create_type_info
> +** allocates memory for a new type_info on the Mercury heap. Since this
> +** may modify MR_hp, you need to wrap save_transient_hp() and
> +** restore_transient_hp() around calls to MR_create_type_info.
> +** MR_make_type_info allocates memory using MR_GC_malloc, and inserts
> +** the address of the cells allocated into the list of allocations
> +** represented by its last argument; it is the caller's responsibility
> +** to call MR_deallocate() on the list after they have finished using
> +** the returned typeinfo.
> +**
> +** MR_create_type_info and MR_make_type_info both assume that all type
> +** variables inside the given pseudo typeinfo are universally quantified.
> +** Their maybe_existq variants do not make this assumption; they also work
> +** if the pseudo typeinfo contains existentially quantified arguments.
> +** This can happen only when the pseudo typeinfo describes the type of
> +** an argument of a function symbol from a MR_TYPE_CTOR_REP_DU* type.

This makes me curious, since there is another place exist vars can occur.

What happens in the case of an existentially quantified type variable
in a higher order type?  I'm not sure that we handle this.


Apart from that I think this diff is OK.

-- 
The quantum sort: 
	while (!sorted) { do_nothing(); }
Tyson Dowd   <tyson at tyse.net>   http://tyse.net/
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------