[m-dev.] Resources example

[Peter Schachte]

On Tue, Apr 26, 2005 at 02:21:22PM +1000, Ralph Becket wrote:
> > 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!

You certainly could.  Except that the parameters would actually still
be (visibly) explicit, so you really couldn't.  And your code would
become much more verbose than without using resources, so you wouldn't
even be tempted to.

If you wanted to do this, you'd have to create and declare a resource
for each argument (or in/out argument pair) of each predicate.
Already this sounds pretty unattractive to me.  Next, at each call,
you could remove all the arguments, but you'd have to add

    using [!.resource1=Term1, !.resource2=Term3, !.resource3=Term3, ...]

after the predicate name.  As I said, no one is going to do that,
because there's no benefit, only cost.  And even if someone did, the
arguments are still there.

The benefit only comes when a predicate that uses a resource calls
another predicate that uses the same resource, in which case you can
pass that resource without mentioning it.  There are plenty of
occasions for using this, but not just anywhere.  And you still have
to declare where it is being passed, so while it doesn't appear in the
call, it does appear in the pred declaration.

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

Not as trivial as you think.  You still have to specify in which call
that resource comes into scope; you can't set it until it's in scope.
And you have to ensure that along all computations paths in that
scope, the resources is set before it is used.  The compiler checks
all that.  And all the preds involved in that code have to mention
that resource in their pred declarations.

OK, the other way you could use resources to shoot yourself in the
foot is to declare all your predicates to use the resource in a
commutative and idempotent way, even though they're not.  But look, if
a user is determined to shoot himself in the foot, we really can't
stop him.  What you're talking about would be much easier with
impurity, and easier still using the C interface.

> 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 don't give you references any more than state variables do.
The fact that you can store references in data structures is what
makes them dangerous, and resources don't give you that.  Resources
are just a new argument passing mechanism.

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

The big explicit ! is also there with resources, and it comes at the
front of the goal, where you can't miss it.  I don't think resources
would make Mercury code less trustworthy, since all argument threading
is still checked by the compiler just as it is now.  You wouldn't
think of your code any differently than you do now.  Resources just
permit you to be explicit about the fact that there is some value
threaded through your code, allow you to name it and specify it's
type, and save you from having to mention it in every clasue head and
everywhere it is called.  And this can be a boon when you need to
change what is being threaded where, and leaves your code much neater
than if you packed and unpacked bundles threads into a single thread.

-- 
Peter Schachte              If we do not succeed, then we run the risk of
schachte at cs.mu.OZ.AU        failure.
www.cs.mu.oz.au/~schachte/      -- Dan Quayle, March 1990 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------