[m-dev.] Proposal: support for module initialisation and state

Ralph Becket rafe at cs.mu.OZ.AU
Fri Jul 8 14:42:36 AEST 2005


It's becoming apparent that some modules need (a) initialization of some
kind (e.g., when interfacing with OpenGL or CPLEX) and/or (b) support
for module-local mutable state (e.g., to hold constraint stores for
solver types).

I propose we add something like the following to the language (the
syntax is purely conjectural; it would be good if we could agree on the
functionality and semantics before we start the obligatory syntax war :-)

INITIALISATION AND FINALISATION

	:- initialisation(pred_name).

Ensures that at start-of-day (i.e., before main is called)
pred_name(!IO) is called.  No initialisation order can be assumed.

	:- finalisation(pred_name).

Ensures that at end-of-day (i.e., after main has returned)
pred_name(!IO) is called.  No finalisation order can be assumed.

MUTABLE STATE

	:- mutable(name, type, inst, initial_value).

The mutable declaration can only appear in the implementation section of
a module and defines a mutable variable.  The compiler constructs access
methods

	:- semipure pred get_name(type::out(inst)) is det.
	:- impure   pred set_name(type::in(inst)) is det.

The set_name predicate trails the current value to ensure changes are
undone on backtracking.

An untrailed_mutable declaration means the same as the mutable declaration
except that the set_name predicate does not trail the current value:

	:- untrailed_mutable(name, type, inst, initial_value).

Comments?

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



More information about the developers mailing list