[mercury-users] re: gsat, Mercury vs functional languages, nondeterminism

[Henk Vandecasteele]

Don Smith wrote:
> 
> Hi,
> 
> Henk wrote:
> > I believe there is nothing wrong with Mercury to implement
> > GSAT-algorithm based on probabilistic methods.
> 
> Thank you for the program code. I did "grep det gsat.m."  Here's what I
> got back:
> 
> :- pred main(io__state::di, io__state::uo) is det.
> :- mode start(in, in, in, array_di, array_uo, in, in, mdi, in, in, out, out) is det.
> :- mode start_climb(in, in, array_di, array_uo, in, out, mdi, muo, in, out) is det.
> :- mode climb(in, array_di, array_uo, mdi, muo) is det.
> :- mode catch(in, in, out) is det.
> :- mode flip(in, array_di, array_uo) is det.
> :- mode climb_iter(in, in, in, in, out, in, array_di, array_uo) is det.
> :- mode check(in, array_ui, out) is det.
> :- mode check_disj(in, array_ui) is semidet.
> :- mode read_formula(in, out, out, out, out, di, uo) is det.
> :- mode read_token(in, out, in, out, in, out, di, uo) is det.
> :- mode read_formula(in, out, in, out, in, out, out, di, uo) is det.
> 
> It didn't even use Mercury's backtracking.
> 
> Tyson wrote:
> > You don't pay anything for non-determinism if you don't use it.
> 
> That's my point:  few applications even need Mercury's nondeterminism. :(
> 
> But you won't pay for it only so long as Mercury's support for full
> unification doesn't infect the deterministic code with overhead.  I can
> see why the Mercury designers want to start with a simple language. But
> so many applications need really expressive support for things like
> unification, intelligent backtracking, stateful computation, and
> randomness.  Unfortunately there's no free lunch.  (But there sure are
> over-priced lunches.)

What you ask for seems like a language that provides a skeleton
algorithm. For different programs is should than behave as:
det, nondet, Inteligent Backtracking, gsat-like algorithm.
To me this seems like an really difficult task. And if one would 
succeed in designing such a skeleton algorithm, few people will
understand/use these features.

I look at Mercury from a totally different perspective:
I see the declarative part of Mercury as support for 90 percent of the
code. The remaining 10 percent I have to do myself, this might be some
stuff about sophisticated data-structures or a specialized algorithm.
If this cannot be done within Mercury, I have no problems in
using the C-interface.

Therefore having a simple and understandable Mercury language is 
important. Of course more support for more sophisticated 
stuff is welcome, but it shouldn't make the language heavier for
the novice user. Providing/hiding such things within libraries 
seems a good thing.

Henk