[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