[m-dev.] Re: Undetected switches

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Feb 7 20:11:52 AEDT 2001


On 07-Feb-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Right.  The reason for this is that the unification `X = A'
> is a "simple_test" unification rather than a deconstruction.

Sorry, s/"simple_test"/"complicated"/

> Here's the old patch from 1997.  I'll post it as is, followed by some
> commentary on what has changed since then.
> 
> ----------
> 
> Two changes:
> 1. When flattening goals to superhomogeneous form, make sure that
>    we order unifications bottom-up, rather than top-down.

That change never made it in, because it caused performance problems
during type checking.  E.g. type checking of compiler/options.m took
much too long.

>This is necessary for several reasons:
> 	- The ordering affects the operational semantics,
> 	  if using the strict-sequential operational semantics.
> 	  The Semantics chapter of the Mercury Language
> 	  Reference Manual says that function calls are
> 	  executed "depth-first left-to-right", which (although
> 	  a bit unclear) is supposed to imply bottom-up
> 	  rather than top-down.

That's still the case; this is still a currently outstanding bug.
The reason it isn't fixed is due to the performance problem mentioned
above.

> 	- When doing mode inference for functions,
> 	  the bottom-up ordering is almost always right, and
> 	  the top-down ordering is almost always wrong.
> 	  Since mode inference doesn't do reordering,
> 	  it is important to pick the right ordering in the
> 	  first place.

Mode inference now does reordering, so that's not so much of an issue.
But we ended up solving that by giving functions a default mode of
`(in, in, ...) = out is det'.  And arguably that is a better approach
than using mode inference for functions.

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