[m-rev.] for review: pure mutable access predicates

Julien Fischer juliensf at cs.mu.OZ.AU
Wed Oct 5 17:04:02 AEST 2005


On Wed, 5 Oct 2005, Ian MacLarty wrote:

> On Wed, 5 Oct 2005, Julien Fischer wrote:
>
> >
> > For review by Ralph or Ian.
> >
> > Estimated hours taken: 7
> > Branches: main
> >
> > Add optional support for generating a pure interface to mutables.
> > This is
> > done by adding a new mutable attribute, `pure'.  If this attribute is
> > specified in the mutable declaration then in addition to the usual
> > non-pure
> > access predicates, the compiler will also add a pair of access
> > predicates that
> > take the IO state.
> >
>
> I would prefer the pure version to be the default and that there be an
> `impure' attribute that generates the impure access predicates.

Only one of the access predicates is impure; the other is semipure
so perhaps the attribute should be called `nonpure'.

> This would be more in line with our current policy of making
> impurity explicit.

It's consistent with our treatment of foreign_procs, which are
also impure by default unless you promise otherwise.

We should wait until we have a bit of experience using mutables
to see how/if this is going to be problem.

> > tests/hard_coded/Mmakefile:
> > tests/hard_coded/pure_mutable.m:
> > tests/hard_coded/pure_mutable.exp:
> > 	Test mutables with pure access predicates.
> >
> > tests/hard_coded/ppc_bug.m:
> > 	Unrelated change: update the comments in this test case so
> > 	they describe what the cause of the bug and the fix were.
>
> You also need to test that io tabling workings properly for the pure
> access predicates.

I have yet to test that intialise/finalise/mutable declarations
properly with debugging/(deep) profiling - I'll add any relevant
test cases when I do.

> > ===================================================================
> > Index: compiler/prog_data.m
> > ===================================================================
> > -:- func prog_mutable.init_pred_decl(module_name, string) = item.
> > -
> > -    % XXX We should probably mangle Name for safety...
> > -    %
> >  :- func mutable_get_pred_sym_name(sym_name, string) = sym_name.
>
> Does this XXX no longer apply?
>
It no longer applies - we started mangling mutable names as part
of an earlier change.

> ...
> > +
> > +	% Return the type io.state.
> > +	% XXX Perhaps this should be in prog_type?
> > +	%
>
> Yes, I think it should.
>
Ok.

> > ===================================================================
> > Index: tests/hard_coded/ppc_bug.m
> > ===================================================================
> > RCS file: /home/mercury1/repository/tests/hard_coded/ppc_bug.m,v
> > retrieving revision 1.1
> > diff -u -r1.1 ppc_bug.m
> > --- tests/hard_coded/ppc_bug.m	2 Dec 2004 07:51:28 -0000	1.1
> > +++ tests/hard_coded/ppc_bug.m	4 Oct 2005 16:33:35 -0000
> > @@ -1,10 +1,13 @@
> > -% The following program compiles incorrectly on PPC/MacOS X
> > -% in grade reg.gc.  find_nth_yes/4 ends up throwing an
> > -% exception instead of returning `YesPos = 3'.  Passing
> > -% `--no-optimize-fulljumps' causes the test to pass.
> > +% The following program compiles incorrectly on PPC/MacOS X in grade
> > reg.gc.
> > +% find_nth_yes/4 ends up throwing an exception instead of returning
> > `YesPos =
> > +% 3'.  Passing `--no-optimize-fulljumps' causes the test to pass.
> >  %
> > -% The test passes with gcc 2.95.2 (Apple version)
> > -% but fails with gcc 3.3 (Apple version).
> > +% The test passes with gcc 2.95.2 (Apple version) but fails with gcc
> > 3.3
> > +% (Apple version).
>
> As far as I know the compiler doesn't compile at all with Apple gcc 2.95
> because that version of gcc can't handle long identifiers.
>

That's correct - but this test case passes if you compile ppc_bug.c
with gcc 2.95.  gcc 2.95 couldn't compile some of the compiler modules
because of long identifiers but there aren't any long identifiers here.

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



More information about the reviews mailing list