[mercury-users] !foo

[Ondrej Bojar]

On Mon, 24 Mar 2003, Peter Schachte wrote:
> On Mon, Mar 24, 2003 at 11:27:53AM +1100, Ralph Becket wrote:
> > My feeling is that state variable syntax should be recognised as just a
> > convenient shorthand and we should not try to pretend it has any direct
> > declarative reading.  That is, we should leave it out of the pred and
> > mode declarations.
>
> That seems undesirable to me.
>
> Firstly, it's just confusing to have predicate declarations not appear
> to match their definitions.  This always bothered me with DCGs, too.
>
> More importantly, failing to support state variables in declarations
> fails to support the mental model I believe people want.  This is a

I'm still quite a new user of Mercury, however my mental preference is
strictly the opposite of yours (and in favour of Ralph Becket's): The main
advantage I felt Mercury had for me, was that it *didn't* allow me to give
the same name to two different things -- a value before an operation and
the value after the operation.  If I used the same name (of the variable),
it was indeed the same thing as before. Then, if I for example
incidentally used the name of the variable before the update instead of
the fresh one, it was *my fault* and this fault was *clearly written* in
the code ("now use the old value of the variable" was there written).

I must admit: once I became trained in this strict way of naming things, I
enjoyed using DCGs as a *syntactic sugar*, and I'd definitely love to use
the state variables as a *syntactic sugar* too.

What I feel is important for new users of Mercury, is the *new* mental
model they should adopt. They won't adopt it, if Mercury is too similar to
what they know from Perl, C, etc.

For all the authors of tutorials and books on Mercury, I personally would
suggest introducing both, the DCGs and the state variables not earlier
than in 'chapter 3'. Prentending that Mercury is 'very similar' to other
languages would definitely gain us more users, but the users might never
be influenced by the purity of Mercury.

(I'm sorry I know nothing about 'monads'.)

Andrew.

> psychological argument, but I believe people really want to think of
> some computations as modifying a value in some way, rather than as
> computing a new thing related to the old thing in some way.  For
> example, do you think of parts of the Mercury compiler as processing
> an HLDS to fill in data, or as computing a new HLDS from an old one by
> adding more information?  When it comes to io states the argument is
> even more compelling, since the mental model of what is going on is
> actually the truth; passing the "state of the world" around is a
> fiction introduced to maintain purity.
>
> This preferred mental model, I believe, is why the Haskell do notation
> makes monads easier:  it allows a more natural mental model of what is
> going on.  I believe Mercury should support and encourage simpler,
> more natural mental models when it can, even if the implementation
> works another way.
>
>

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