[m-dev.] more on determinacy checking

[Fergus Henderson]

On 05-Dec-1997, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> Just after deleting all the messages on this subject, I realized there may
> be another solution to this problem.
> 
> I think the problem arises because switch detection is used both for
> determinacy checking/inference and for, well, switch detection.  But there's
> nothing to say you can't use switch detection just for determinacy.
> 
> So here's a proposal.  Analyze the code as you do now.  If you get a
> determinacy error, then switch into "try harder" mode and try again,

At least for the purposes of describing the language, I'd prefer it
if there was just one mode; the implementation might use two modes,
but that would just be a performance hack.

Having a "try harder" mode makes determinism inference fairly tricky.
If you get a determinism error in pred p, then you may need to enable
"try harder" mode in any or all of the preds it calls.  In fact to solve
this you'd basically have to run the "try harder" mode for every procedure
whose determinism is to be inferred (and for each fixpoint analysis step);
then, when the determinisms have been inferred, you could go back and do
the ordinary mode of switch detection.

> this
> time not stopping at any call of any kind (consider the whole body of the
> pred). If you don't find a switch, fine, it's really a determinacy error. 
> If you do, and it turns out the proc really is deterministic, then there's
> no determinacy error. In this case, if --strict-sequential was not selected,
> then go ahead and turn it into a switch.  If --strict-sequential was
> selected, then you can't actually turn it into a switch, but that doesn't
> change the fact that the proc really is deterministic. 
>
> Would this work?

Hmm.  I think so.

I guess we'd need a field in every disjunction saying whether or
not it was switchable.  Switch detection would set this, for switches
that could be turned into disjunctions if it weren't for --strict-sequential.
Determinism analysis would use this information.

There's another problem, though.  I'm a bit worried about possible
interactions with `cc_multi', and with unique modes.  Reordering done
by switch detection might affect both of those.  So if we make switch
detection do the reordering only if `--strict-sequential' is not set,
then compiling with `--strict-sequential' might affect whether or not
you get errors for incorrect use of unique modes or committed choice
determinisms.  This is undesirable, because it would harm the
portability aims of `--strict-sequential'.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.