[m-dev.] for review: compiler-generated procedures

[Fergus Henderson]

On 01-Oct-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > > +			{ construct_type(unqualified("int") - 0, [],
> > > +				IntType) },
> > 
> > Better to use the int_type/0 function in type_util.m.
> 
> Then why doesn't the rest of unify_proc.m, which I copied from use that
> predicate? :-( Because it predates that predicate, I expect.

Indeed.

> Here is a relative diff.  Note that the only reason why I call builtin:unify
> on two integers is that there is no builtin_int_eq, even though there is
> builtin_int_{lt,gt}.

There is a builtin_int_eq, though not with that name --
it's called `builtin_unify_int'.

...
>  	;
>  		{ TypeBody = eqv_type(_Type) },
> -		% We should check whether _Type is abstract or not.
> -		% If it is, we should call its unification procedure;
> -		% if it is not, we should generate its body inline here.
> +		% We should check whether _Type is a type variable,
> +		% an abstract type or a concrete type.
> +		% If it is type variable, then we should generate the same code
> +		% we generate now. If it is an abstract type, we should call
> +		% its unification procedure directly; if it is a concrete type,
> +		% we should generate the body of its unification procedure
> +		% inline here.
> +		%
> +		% XXX Somebody should document here what the later stages
> +		% of the compiler do to prevent an infinite recursion here.

I suggest you replace that XXX comment with

		% Note that equivalence types are not allowed to be recursive
		% (this is checked by compiler/equiv_type.m),
		% so we can't get infinite recursion here.

> @@ -581,8 +603,16 @@
>  		)
>  	;
>  		{ TypeBody = eqv_type(_Type) },
> -		% XXX zs: I believe this code works only by accident.
> -		% XXX the point for unify also applies here
> +		% We should check whether _Type is a type variable,
> +		% an abstract type or a concrete type.
> +		% If it is type variable, then we should generate the same code
> +		% we generate now. If it is an abstract type, we should call
> +		% its index procedure directly; if it is a concrete type,
> +		% we should generate the body of its index procedure
> +		% inline here.
> +		%
> +		% XXX Somebody should document here what the later stages
> +		% of the compiler do to prevent an infinite recursion here.

Likewise.

>  	;
>  		{ TypeBody = eqv_type(_) },
> +		% We should check whether _Type is a type variable,
> +		% an abstract type or a concrete type.
> +		% If it is type variable, then we should generate the same code
> +		% we generate now. If it is an abstract type, we should call
> +		% its compare procedure directly; if it is a concrete type,
> +		% we should generate the body of its compare procedure
> +		% inline here.
> +		%
> +		% XXX Somebody should document here what the later stages
> +		% of the compiler do to prevent an infinite recursion here.
>  		{ ArgVars = [Res, H1, H2] },
>  		unify_proc__build_call("compare", ArgVars, Context, Goal),

Likewise.

Apart from those points, this looks fine.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------