[mercury-users] Mercury needs a Tutorial

Ralph Becket rwab1 at cam.sri.com
Mon Feb 15 20:37:47 AEDT 1999


David Powers wrote on 15 Feb:
> 
> Looks good - I'll keep comments/corrections brief.
> 
> In your program you have
> 
> :- import_module io.
> 
> In your explanation you have
> 
> :- use_module io.

Got it.

> The idea of programs having input/output parameters will be familiar to those 
> who learnt strict Jensen&Wirth Pascal (program asdf(input,output)).

That's quite a small minority, n'est pas?

> Is "token" the appropriate word to describe "__" (something higher level
> like operator perhaps)?

Hmm.  You're probably right.

> Rather than "some punctuation symbol" how about "something non-alphabetic" 
> (e.g. numbers start with digits).

I was thinking in terms of names added by the user (i.e.
pred/type/mode/inst names), some of which are non-alphabetic (e.g.
+/2).

> "Think mathematically and you'll be fine!" is the last thing I would say to my
> students...  They'd run a mile...

Oh dear...

> Most examples came out centred (line by line), which looks a bit strange...  I
> guess this'll work out in the wash, or it may be exmh (I see you did centre 
> tables - the part before <p> was centred within the table, while the part 
> afterwards was indented as well as can be expected as I saw in the fibonacci 
> example).

Sounds like an exmh'ism.  However, I've taken out the centreing
all-together now.

> Given that doing the factorial examples like this in Prolog would
> return the sum of the appropriate number of 1's, do I assume that = acts like 
> Prolog's is and evaluates expressions.  Moreoever the fibonacci example would 
> fail due to predicates not being evaluated and the non-existence of functions.

Correct.  What I think this thing is going to need is a brief
introduction warning the non-Prolog types what to expect and the
Prolog types which assumptions to avoid making.

> Interesting.  It may be worth explicitly highlighting differences
> from Prolog like this.  The use of {...} needs to be spelled out a

There is a Prolog --> Mercury transition guide in the doc's.

> little more explicitly, at least actually quoting the relevant line
> rather than expecting the reader to look back, hunt for the braces
> (hard in my font) and figure what you are talking about and why (-->
> adds to all predicates, not functions in both head and tail and
> factorial doesn't do I/O and the definition doesn't have I/O
> arguments.  I'm a Prolog programmer and NL expert, and I had to make
> a little effort to connect your {...} comment with the DCG shorthand
> and had skimmed past them without noticing. (Unlike those who
> suggested that introducing DCG notation in your first example was
> too much, I think it is appropriate to show the simpler surface
> form.)

It's not an easy call to make.  I'll probably make the expansion
explicit here.

> In teaching Prolog I strongly discourage use of ; (probably pretty
> common), and also -> ; (less common).  Possibly it is only the
> nesting of these I should discourage, particularly as there are
> optimizations which are lost by doing so.  It may be worth
> commenting on this (to Prolog programmers) if there are special
> reasons why these are used in Mercury where they would not be in
> Prolog.

It's common practice in Mercury to use both disjunction and
if-then-else.  If-then-else is probably a matter of taste - I prefer
it because it's got a more declarative flavour (if not texture) than
cut under Prolog.

I'm going to talk about multiple-clause notation in the next chapter
on determinism and backtracking.

> So far so good...
> 
> Thanks for the effort, Looking forward to the next installment!

Thanks for the feedback!

Ralph

-- 
Ralph Becket  |  rwab1 at cam.sri.com  |  http://www.cam.sri.com/people/becket.html



More information about the users mailing list