[m-rev.] for review: mutables and intermodule optimization

Ralph Becket rafe at cs.mu.OZ.AU
Fri Sep 16 19:09:39 AEST 2005


Julien Fischer, Friday, 16 September 2005:
> 
> The following diff fixes a problem with mutables and intermodule optimization.
> It raises a couple of issues:

This is almost exactly the same as a diff I forgot to post this morning!

> Should the globals used to implement mutables be external or local?  Currently
> they are the former, and I think this ought to be the case as doing otherwise
> would prevent us inlining the access predicates across module boundaries.
> (Another option here is to have a `local' attribute for the mutable and only
> export clauses for the access predicates in the .opt  files if that attribute
> is not set.)

A better solution might be to allow mutable declarations in the interface 
section.  Such a mutable would be exported at the Mercury and C levels.

> We don't currently mangle the name the name of the global variable used to
> implement a mutable (currently that's an XXX).  The diff below prefixes the
> name of the global with that of the module.  It results in rather unwieldy
> variable names on the C side of the FLI - which could be an annoyance for
> writers of library bindings etc.

Not a problem: that's what #define is for.

> Some suggestions as to what could be done about this:
> 
> (1) Don't module qualify the global names - this means that the
>     programmer has to ensure that conflicts don't occur.
> 
> (2) Module qualify them.
> 
> (3) Module qualify them, but allow the programmer to override that
>     name if they wish, e.g a `foreign_name' attribute.

What's wrong with the (2) plus advice in the documentation regarding
using #define to come up with a more convenient alias if necessary?  I
honestly don't think (1) is a good idea or that (3) is necessary.

> Branches: main
> 
> Make the declarations for the global variables used to implement mutables
> visible across module boundaries.  This can be a problem if the access
> predicates are inlined across module boundaries.
> 
> compiler/make_hlds_passes.m:
> 	Make sure that there is a declaration for the global variable
> 	in the module's .mh file.
> 
> compiler/prog_mutable.m:
> 	Append the module name to the name of the global variable
> 	used to implement the mutable.

This looks fine to me.

-- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list