[m-dev.] Resources example

[Ralph Becket]

Peter Schachte, Tuesday, 26 April 2005:
> 
> You can still only do things you could do by threading extra
> arguments.  There's nothing non-backtrackable here, as there may be
> when using impurity to modify global state.  We also don't need to
> rely on the implementation details of a pragma for correctness, as the
> original code does.

It is well known that you can get yourself into plenty of trouble with
implicit state, even without backtracking.  I seem to recall that being
one of the key motivations for declarative languages :-)

> As for the wider argument that having resources creates a large scope
> for abuse, I disagree.  Firstly, impurity creates a far larger
> opportunity for abuse, and I don't get the impression that this has
> proved to be a problem.

To date impurity has been sufficiently awkward (deliberately) that it
has not been widely used.  Although we have still seen regular "abuse"
for things like impure.m.

> And secondly, I don't think anyone would
> abuse the feature in the way I imagine you are worried about:  passing
> too many inputs and outputs as resources.  Unless a value is being
> threaded through much code, using resources to pass it around is more
> verbose and less convenient than just passing ordinary arguments.

Surely using this argument I could make *all* my parameters disappear!

I would lay money on resources being abused because resources make it
trivial to implement variables with assignment.

Here's the rub: ML and OCaml programs are harder to trust/maintain/
optimize/debug than Mercury programs because they support references
which are used as a matter of course by ML programmers.  But at least
they have to explicitly pass the references around; with resources I
don't even have to do that.

> Resources are only really usable where some entity is threaded through
> many predicates, such as an io__state through I/O code, or a variable
> counter through a term parser that needs to allocate variable numbers.
> Or for threading a solver state.  In such cases, a resource is a win
> because it's given an enforced consistent name everywhere, and the
> type is only specified once, making maintenance easier.  Also, by
> making argument lists shorter, they make it easier for a human to
> match up actual and formal parameters, or to change which resources
> are threaded where.

I agree with all your arguments for resources.  However, I also belive
that resources would make Mercury programs less trustworthy etc.  For
one thing, f(X) \= f(X) if f uses a resource, so referential
transparency goes right out the window.  The same is true of state
variables, but at least with state variables there is a big explicit !
to tell you that imperative-style things are afoot.

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