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

[Julien Fischer]

On Fri, 16 Sep 2005, Ralph Becket wrote:

> 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!
>
Great minds think alike ;-)

> > 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.
>
I think mutables should be module local at the Mercury level, if you want
to export access to a mutable in Mercury then you need to go and do so
yourself - the issue here is should the compiler be allowed to export
access to them.

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

What's wrong with (2) is another change I just made mangles the
variable names correctly - documenting that would requires us to
include details of the mangling algorithm in the reference manual.

I'm leaning towards (3) myself, even if all (3) does is generate
appropriate #defines as you suggest.

Cheers,
Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------