[m-dev.] for review: changes to MLDS

[Julien Fischer]

On Wed, 31 Jan 2001, Fergus Henderson wrote:

> On 31-Jan-2001, Julien Fischer <juliensf at students.cs.mu.oz.au> wrote:
> >  ml_initial_cont(OutputVarLvals0, OutputVarTypes0, Cont) -->
> > -	ml_qualify_var("cont", ContLval),
> > -	ml_qualify_var("cont_env_ptr", ContEnvLval),
> >  	{ ml_skip_dummy_argument_types(OutputVarTypes0, OutputVarLvals0,
> >  		OutputVarTypes, OutputVarLvals) },
> >  	list__map_foldl(ml_gen_type, OutputVarTypes, MLDS_OutputVarTypes),
> > +	ml_gen_var_lval("cont", mlds__cont_type(MLDS_OutputVarTypes), ContLval),
> > +	ml_gen_var_lval("cont_env_ptr", mlds__generic_env_ptr_type,
> > +		ContEnvLval),
> >  	{ Cont = success_cont(lval(ContLval), lval(ContEnvLval),
> >  		MLDS_OutputVarTypes, OutputVarLvals) }.
> 
> I think that should be `mlds__cont_type([])' when the
> `--nondet-copy-out' option is not enabled.

This is already checked when ml_initial_cont is called (it's called twice,
once in ml_code_gen.m and again in ml_unify_gen.m) and if 
`--nondet-copy-out' is not enabled OutputVarTypes0 = [].
We could put a comment here to the effect that ml_inital_cont expects
OutputVarTypes0 = [] if --nondet-copy-out is not enabled.  Unless
you think that we should check this within ml_inital_cont as well. 


> > --- compiler/mlds.m	2001/01/17 17:37:17	1.45
> > +++ compiler/mlds.m	2001/01/31 01:41:59
> > @@ -547,8 +547,15 @@
> >  
> >  	;	mlds__pseudo_type_info_type
> >  	
> > -	;	mlds__rtti_type(rtti_name).
> > +	;	mlds__rtti_type(rtti_name)
> >  
> > +		% A type used internally by the ML code generator to 
> > +		% mark variables whose type is yet to be generated.  This
> > +		% occurs once in ml_code_util.m where env_ptr's are created,
> > +		% but their type remains unknown until the ml_elim_nested.m
> > +		% pass.  
> > +	;	mlds__unknown_type.
> 
> The comment here is misleading, because it suggests that the ml_elim_nested.m
> will replace all occurrences of mlds__unknown_type with the right value.
> But that pass doesn't do that.  Instead it leaves them as mlds__unknown_type.

This has me a bit confused.  I thought the idea was that ml_code_util.m
generated the env_ptr's as dangling references and ml_elim_nested resolved 
them.  If that isn't the case then where are the types for the env_ptr's
being generated?  The idea was that at some point the mlds__unknown_types
should be replaced by whatever types they're supposed to be (at least if
everything is working correctly). 

Julien

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------