[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