[mercury-users] Uniqueness modes etc

[Dr Mark H Phillips]

Hi Fergus,

Thanks for your reply!  I agree that monads are a difficult 
concept (associated with other difficult concepts) to get one's
head around.  I am relatively new to them myself and still have
a way to go in my understanding of them.

I hope you don't mind if I attempt to argue the case for the
support of monads.  I do realize you have much more experience 
in declarative programming than I, but from my reading about
monads so far they do seem to have a bit going for them.

At their essence, monads seem to be anything which encapsulates
(in a certain way) the plumbing together of a sequence of "effectful
computations".  Any sequence able to be formed using a monad, is equally
able to be created using "manual plumbing".  So one might think that
they don't add anything "substantial" to the language.  From what
I can work out though I think they can "add" in a two key ways:

1. They encapsulate the sequence plumbing.  This allows separation
of ones problem into two parts: what steps are being sequenced 
together, and how any such sequencing should be performed.  This
in turn allows the same sequence of steps to be easily put together
in a variety of different ways, or the same form of sequencing
performed to a variety of different sequences of steps.  Generic
algorithms can be developed based on this separation.  The ability
to reason about "effectful computations" (and perform 
meta-computations on them) is enhanced.

2. They provide a framework for hinting to the compiler about
modify-in-place optimizations and IO.  A pure declarative language
can't actually perform modify-in-place, but it can model it and 
hope that "wink wink, nudge nudge" the compiler will turn these 
models into actual IO and variable modify-in-place.

It seems to me (and please do correct me if I'm wrong) that
uniqueness modes really are an alternative form of 2.  That is,
by giving a pred a di-uo pair of modes we are really saying
"wink wink, nudge nudge" perhaps the compiler will do a 
modify-in-place here.

The advantage of Mercury's approach over monads, it seems to me,
is that the former seems like a much more direct hint to the
compiler and much closer conceptually to actual modify-in-place.
I suspect that is why you say Mercury's approach is often clearer
and easier to understand.

I don't see why Haskell doesn't add some form of uniqueness typing
(or modes) and use these as an intermediate step between some of
their monads and the compiler.  This would allow a more explicit
form of hinting, allow more to be done "within the language" rather
than "within the compiler", and would facilitate users writing
their own (not using special compiler supported libraries)
modify-in-place solutions.  Perhaps I am not seeing things clearly
here, but this is my current impression.

The flip side of the coin here of course, is that Mercury doesn't
properly support the use of monads along the lines of 1.  Now 
perhaps what you are saying is that many of the typical uses of
monads in this way, are possible using other (uniqueness based)
techniques.  My gut feeling --- but I could be wrong here --- is 
that there are some powerful techniques out there (many probably 
not even discovered yet) which are only expressible using monads
or related concepts.

My thought was that Mercury might be well placed to get the best
of both worlds.  However I am very new to all these ideas so
I could easily be wrong to think that adding monad support to
Mercury would be a significant gain.

Cheers,

Mark.

On Mon, 2004-01-12 at 21:40, Fergus Henderson wrote:
> On 12-Jan-2004, Dr Mark H Phillips <mark at austrics.com.au> wrote:
> > 
> > Is there monad support already in Mercury?
> 
> No.
> 
> Currently Mercury doesn't support constructor classes, which would be
> needed to implement a monad type class like Haskell has.  You should be
> able to implement particular monads, e.g. the list monad, without much
> difficulty, but it's not so easy to abstract over all of them.
> 
> Monads are difficult to understand -- witness the long discussion
> about monads which is currently running on comp.lang.functional.
> This difficulty of understanding in part to historical reasons and in
> part to the use of unintuitive nomenclature, but is also to some degree
> inherent, because the monad type class is a very abstract, and because
> it relies on other complicated constructs like higher-order functions,
> continuation passing, and constructor classes.  Furthermore, unless
> you use some syntactic sugar, code written using monads is quite ugly.
> 
> In many cases, code written without monads can be clearer.  For example,
> Mercury's store type, which is Mercury's alternative to Glasgow Haskell's
> state monad, is IMHO easier to understand and to use than GHC's state monad.
> With GHC's state monad, it is not possible to simply create a state
> and then update it -- instead you have to create a computation which
> will manipulate a state and then use a higher-order function "runST" to
> invoke your computation.  GHC's state monad also relies on first-class
> polymorphism, which is a type system extension not present in standard
> Haskell or Mercury.
> 
> So, even if we did support constructor classes, I'm not sure if I would
> want to then provide special syntactic sugar for monads.  Mercury provides
> other alternatives for most of the uses of monads, and there would be
> little incentive for us to provide special syntactic sugar for something
> which would rarely be used.

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------