[m-dev.] the next release (0.12)

Ralph Becket rafe at cs.mu.OZ.AU
Fri Jul 16 14:23:38 AEST 2004

Julien Fischer, Wednesday,  7 July 2004:
> Library
> -------
> * cleanup
> * string.string	(rafe)
> 	-- seems to have started throwing errors
> * func versions of preds with (in, in, in) = out is det modes (rafe)
> * add preds with state variable friendly argument orderings (rafe)

We have a number of predicates in the library with unfortunate parameter
orderings with regard to the interface to both the higher order
programming support in the library and the use of state variables.

The typical offender looks like this:

:- pred update_thing(thing::in, _::in, _::in, thing::out) is detism.

The "proper" order of parameters should be

:- pred update_thing(_::in, _::in, thing::in, thing::out) is detism.

It would be awkward and ugly to have to come up with alternative names
for each such predicate in order to provide a state-variable friendly
version.  I really don't want to have to introduce names like

:- pred update_thing_sv(_::in, _::in, thing::in, thing::out) is detism.

Can I propose that we just `:- pragma obsolete ...' these predicates
for version 0.12 and put higher-order/state-variable friendly version in
nested sub-modules called "state_var_friendly", along with a comment
to the effect that in the next version the state-variable versions will
migrate to replace the obsolete versions?

The advantages of this method are that (a) we avoid polluting the name
space, (b) users need only introduce an extra import_module to get at
the sub-module versions for now, and (c) overloading resolution should
mean users shouldn't have to rename uses of the new predicate versions
in the next release.

Any takers?

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