[m-dev.] Re: for review: accumulator introduction

[Lee Naish]

Peter Ross <petdr at cs.mu.OZ.AU> writes:

>+% The constraint on the transformation is that the compose goal must
>+% obey the following law
>+%      
>+%	compose(I, B, C, BC), compose(I, A, BC, ABC)
>+%		<=> compose(I, A, B, AB), compose(I, AB, C, ABC)

Best add quantifiers: some [BC] (...) <=> some [AB] (...)
to avoid confusion (see much earlier discussion) and mention
"associative".

Also worth mentioning which direction the transformation uses (perhaps
swap sides of the <=> to make it more intuitive?), how the compiler
knows/can be told the equivalence holds, and what the efficiency
pitfalls are and how they are avoided (and should be avoided in the
future).  These things are somewhat subtle so its definitely worth
putting a decent effort into the high level documentation.

>+	% XXX this fact table is only a temporary solution to whether or
>+	% not a particular procedure is associative.  In the long term
>+	% the user should be able to annotate their code to indicate
>+	% which predicates are associative.
>+	%
>+	% The set is simply the set of vars that must be static.  It is
>+	% a simple heuristic to ensure that the O() behaviour only
>+	% improves.  ie for append after swapping the arguments the
>+	% static variable must be in the first location.

Add more extensive documentation here(?), with example of append going
wrong?

Also, comments here should not be indented, I think??


>+/* XXX introducing accumulators for floating point numbers can be bad.

Best mention the reason: the operations are typically *not* associative.
There should be some way to locally prevent the order of floating point
operations being changed by the compiler.

For that matter, the same applies to ints (because of overflow).  This
should at least be XXX documented.

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