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

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Jan 31 15:53:20 AEDT 2001


On 31-Jan-2001, Julien Fischer <juliensf at students.cs.mu.oz.au> wrote:
> 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.

That would be great.

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

Yes, that's correct. ml_code_util.m generates references to `env_ptr',
and ml_elim_nested generates definitions for `env_ptr'.

But ml_elim_nested.m does NOT go back and change the types in the
references generated by ml_code_util.m from `mlds__unknown_type'
to the correct type.

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

The idea sounds good, but the problem is that the code doesn't do that,
and the documentation here implies that it does.

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



More information about the developers mailing list