[m-dev.] trace goal `state' parameters

[Ondrej Bojar]

Hi,

I'm not sure if I understand correctly. Your plan is to disallow:

:- mutable(my_mut, my_mut_type, my_mut_init, ground, [untrailed]).

   ...
   trace[state(my_mut, !M)] TraceGoal(!M),
   ...

but this would still work:

   ...
   trace [] some [!M] (
     get_my_mut(!:M),
     TraceGoal(!M),
     set_my_mut(!.M)
   ),
   ...

If I'm correct, I cannot object to the change proposed, all I would need to do 
is a couple of code tweaking to get the same functionality.

If the second example does not work now or will not work later, please let me 
know how to write it correctly.

Cheers, Ondrej.


Julien Fischer wrote:
> 
> Currently trace goals support a "state" parameter that allows one to 
> specify
> the name of a mutable and the name of a state variable that is used to
> thread the value of the mutable through the body of the trace goal.  This
> arrangement is currently a bit delicate w.r.t intermodule optimization.  If
> the clause containing the trace goal ends up in the .opt file there is no
> guarantee that the predmode decls for the mutable access preds will also 
> end
> up there.
> 
> Another minor problem is that the compiler does deal with attempts to
> specify a constant mutable in the state parameter particularly gracefully.
> (You will get an error message about a missing set_ predicate).
> 
> In fact state parameters aren't really as useful as they might seem since
> they are implicitly subject to the same visibility restrictions that
> mutables are.  For mutables these restrictions are what we want** but it
> doesn't really make sense for state parameters.  The logging example in the
> reference manual is a case in point; I would like to be able to refer to 
> the
> logging level in many modules - it is truly global, however mutables are
> (intentionally) module local.  Currently the only way to "export" a mutable
> it to manually introduce access predicates for it in the interface of a
> module.  (This won't work with trace goals since the transformation that
> handles state parameters knows nothing of the manually introduced
> predicates.)
> 
> (** at least they were the ones we wanted when we designed mutables)
> 
> As I see it we can either remove support for state parameters in trace
> goals or modify the compiler's support for mutables to make them work
> safely.  The latter IMO will be a fairly large piece of work since it
> involves adding several things, e.g. exported mutables, that the current
> implementation was never designed to handle.
> 
> My choice would be to remove support for state parameters.
> 
> Julien.
> --------------------------------------------------------------------------
> mercury-developers mailing list
> Post messages to:       mercury-developers at csse.unimelb.edu.au
> Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
> Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
> --------------------------------------------------------------------------

-- 
Ondrej Bojar (mailto:obo at cuni.cz / bojar at ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------