[m-dev.] for review: MLDS code generator design

[Fergus Henderson]

On 05-Aug-1999, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> 
> It would be a good idea to explain what the notation means a little more
> (e.g. do and &&) and how you expect continuations to work.

I'm not sure how to go about addressing that review comment.
The documentation that you were reviewing, which is now in
ml_code_gen.m, includes the following text.  Is this adequate?
If not, could you please explain how it should be improved?

For the "do" and "&&" notation:

    % The calling convention for sub-goals is as follows.
    %
    %	model_det goal:
    %		On success, fall through.
    %		(May clobber `succeeded'.)
    %	model_semi goal:
    %		On success, set `succeeded' to TRUE and fall through.
    %		On failure, set `succeeded' to FALSE and fall through.
    %	multi/nondet goal:
    %		On success, call the current success continuation.
    %		On failure, fall through.
    %		(May clobber `succeeded' in either case.)
    %
    % In comments, we use the following notation to distinguish between
    % these three.
    %
    %	model_det goal:
    %		<do Goal>
    %			This means execute Goal (which must be model_det).
    %	model_semi goal:
    %		<succeeded = Goal>
    %			This means execute Goal, and set `succeeded' to
    %			TRUE if the goal succeeds and FALSE if it fails.
    %	model_non goal:
    %		<Goal && CONT()>
    %			This means execute Goal, calling the success
    %			continuation function CONT() if it succeeds,
    %			and falling through if it fails.
    %
    % The notation 
    %
    %	[situation]:
    %		<[construct]>
    %	===>
    %		[code]
    %
    % means that in the situation described by [situation],
    % for the the specified [construct] we will generate the specified [code].

For continuations:

    % For nondeterministic predicates, we generate code using an explicit
    % continuation passing style.  Each nondeterministic predicate gets
    % translated into a function which takes an extra parameter which is a
    % function pointer that points to the success continuation.  On success,
    % the function calls its success continuation, and on failure it returns.
    
    % To keep things easy, this pass generates code which may contain nested
    % functions; if the target language doesn't support nested functions (or
    % doesn't support them _efficiently_) then a later MLDS->MLDS simplification
    % pass will convert it to a form that does not use nested functions.
    
    % Note that when we take the address of a nested function, we only ever
    % do two things with it: pass it as a continuation argument, or call it.
    % The continuations are never returned and never stored inside heap objects
    % or global variables.  These conditions are sufficient to ensure that
    % we never keep the address of a nested function after the containing
    % functions has returned, so we won't get any dangling continuations.

(The last paragraph is new, added to address Zoltan's review comments;
it wasn't in the documentation that Tyson reviewed.)

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