[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