[m-dev.] location of assertions

Peter Wang novalazy at gmail.com
Mon Jul 9 11:55:22 AEST 2012


On Mon, 9 Jul 2012 02:40:23 +1000 (EST), Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> >
> > However, there is (currently?) a restriction that assertions in the
> > interface can't refer to any symbols defined in the implementation
> 
> As you would expect.
> 
> > or another module.
> 
> That might be more problematic.

I think the restriction was only intended as a short-term measure:

http://www.mercury.cs.mu.oz.au/mailing-lists/mercury-developers/mercury-developers.9907/0265.html

It's reasonable to write an assertion in one module which makes use of
symbols from another module:

http://www.mercury.cs.mu.oz.au/mailing-lists/mercury-developers/mercury-developers.9908/0117.html

> > This is checked while compiling, but not while
> > making the interface file.  I wonder if we can use the restriction to
> > module-qualify assertions unambiguously.
> 
> By restricting assertions made about a predicate to the module that
> declares the predicate?  For associativity, commutivity and state update
> assertions that doesn't seem to be an issue.  In principle, it could
> be a problem for construction equivalence assertions, but in practice
> I suspect it wouldn't be.  (Or at the least, that programmers could
> live with that restriction.)

We could require that assertions in the interface have fully-qualified
references to any symbols outside of the current module.  Unqualified
symbols would be qualified to the current module when making the
interface file.

In the long term, I think the fix is the same as for the problem
where intermodule optimisation introduces ambiguity.

Peter
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list