[m-users.] Mercury Crash Course

[Julian Fondren]

On 2019-08-05 20:33, Philip White wrote:
> 
> Boring thing I noticed. In section 5.1 you are missing the word "not",
> if I'm understanding correctly:
> 
> You would want to loop over valid solutions with the 'solutions' module
> and print the solutions out, and this relatively mundane code would
> [not] be very different in Mercury.

In Prolog you'd interactively get all the solutions, or use a
failure-driven loop to print them out. In Mercury you'd use the
solutions module. So this is mundane code, that has nothing to do
with the puzzle, but it's very different. Meanwhile the code that's
heavily involved in the puzzle is more similar between the
languages.

So I mean it without the 'not'. Thanks though :)

> 
> I think my biggest hurdle in learning Mercury is that I constantly
> wonder why things are the way they are and how I should choose between
> different ways of doing things (perhaps it's not the case, but it feels
> like Mercury provides many ways of doing the same thing, and that often
> certain ways are way better than others) . The crash course does quite 
> a
> good job answering these questions, so good job.
> 
> One thing I'm wondering follows from 3.9. Functions are just a specific
> kind of predicate, but with more convenient syntax. If a predicate
> satisfies the conditions of a function, is there ever downside to 
> making
> it a function? I would think no. If this is correct, perhaps add a
> warning for predicates that could be functions (opt-in to avoid warning
> overload).
> 

A predicate asserts a relationship among some values, but a
function maps an input to an output. I guess you mean that a
predicate that could be a function is one that's deterministic,
with 'out' parameter and otherwise all 'in' parameters, but that
might just be the one use you're getting out of that relationship
so far in a program. You could come along later and add other uses.
Mercury warnings can't be based on how the programmer thinks about
a predicate.

> 
> Perhaps the crash course could have a section on how to find
> documentation; that is always a trouble for me it seems. Ways I've been
> doing it are:
> 

What I'd prefer is a CLI tool that can dump relevant definitions
from installed modules, and sections from the manual. 'perldoc -f
func' and 'perldoc SomeModule' and related tools have always been
great. And the readier that is, the more encouraged others might be
to add stdlib-style documentation to their modules.

> 1. Search through the compiler source code
> 2. Read the language reference manual
> 3. Read the Ralph Becket tutorial (not very complete).
> 4. Hope google has an answer for me (never works).
> 
> It would also be nice to have an easy way to constantly keep a full
> archive of the mailing list offline for quick grepping and bash-fu. 
> Does
> anybody know of tools for this?
> 

The URLs are very regular. I just downloaded them with a bash oneliner.

Cheers.