[Haskell-cafe] Learn Prolog...
jerzy.karczmarczuk at info.unicaen.fr
jerzy.karczmarczuk at info.unicaen.fr
Sun Sep 2 08:51:41 EDT 2007
Andrew Coppin writes:
> Ever tried implementing Haskell in Haskell? ;-)
Haskell is a *complicated* language, needing a parser, which by itself is
a non-trivial exercice. Moreover, it has a type-inference engine, which
may be simulated, sure, but Haskell in Haskell is a tough job.
However, typing Haskell in Haskell is doable, see:
The point is that Mark Jones is a well known Haskell guru, the creator of
Gofer/Hugs, not an average student...
Lisp/Scheme in Scheme is simpler, and is also a pretty standard exercice.
Prolog is also from this perspective, very simple. Terms and clauses have
the same syntax, the "program", i.e., the database of assertions can be
dynamically extended, etc. A real fun.
>> Prolog strategies are straightforward, and I simply cannot understand the
>> comments of Andrew Coppin. Which arbitrary set of conclusions?? Which
>> patently obvious results not derivable?? Be kind, give some examples,
>> otherwise people may suspect that you are issuing vacuous statements...
> Read my whole message. What I was saying (in essence) is that Prolog
> seemed to be performing "impossible" feats of logical deduction - until I
> saw a unification algorithm implemented in Haskell, and then it all made
> (They showed an example where you basically program in a list of who is
> related to who, and then the computer suddenly seems to be able to
> magically deduce arbitrary family relationships - without any code for
> doing this being defined. This seemed utterly far-out to me... I'm not
> used to computers begin able to "think" for themselves. I'm more used to
> having them blindly follow whatever broken sequence of commands you feed
> to them... And yet, given a set of facts, this Prolog interpreter seemed
> to be able to magically derive arbitrarily complex conclusions from them.
> Double-impossible! Until I learned how it's implemented...)
My deepest congratulations. It seems that you are the first person in my
pedagogical life, who got acquainted with the unification through its
implementation in Haskell. Gosh, why I gave to my students the assignment
to construct an unifier in a functional language, when I was absolutely
sure that they understood well the unification itself?...
Actually, perhaps if you tried to do it otherwise, you *would* recognize
that programs in Prolog do not "think", but just constitute a database of
clauses/terms, which undergo a sufficiently powerful pattern-matching. It
is the only "intelligence" inside, helped by the logic protocol, different
from the functional one, which ensures that a predicate in Prolog may
treat *all* its parameters either as input or an output, while in Haskell
this is fixed.
> Having said all that, I still don't "get" what the purpose of the "cut"
> operator is.
Imagine that your life is a path through a tree. Depth first. At every
branching you choose a branch, and you continue. When you are stuck, you
remember that you have left a trail behind you, and you backtrack until
the last choice point. Then you choose another path, the previous being
marked as 'seen'.
Well, the cut is a commitment. You cut your way back, Now, you must succeed,
i.e., find a terminal node which gives you what you want, or your failure
is definitive, you jump out of the system. There are hundreds of easy
examples of cuts, e.g., when descending the tree consumes the ressources
which cannot be restored.
The cut is criticized sometimes as something "not logical", a pragmatic
> I also failed to understand the Prolog syntax description.
> (What the heck is an "atom" when it's at home? I thought an atom is a unit
> composed of protons and electrons...)
Now, you are pulling my leg. An "atom" means that you cannot split it in
constituents, this name came from Lisp into other languages, but the meaning
comes from Democritus, who didn't know protons. I won't say more, just that
if you want to be really funny, you should not forget neutrons.
> I can certainly see why Prolog would be very useful for certain types of
> problems. As it happens, not the kind of problems that usually interest
> me. ;-)
Well, who am I or other readers to contradict it?...
My point was that learning more than one language (and moreover, not so
well) gives you a better perspective to learn the ESSENCE. Let's terminate
by two citations from Democritus, who invented atoms:
# "Nature and instruction are similar; for instruction transforms the
man."(DK 68 B 33)
# "If any man listens to my opinions, here recorded, with intelligence, he
will achieve many things worthy of a good man, and avoid doing many unworthy
things.(DK 68 B 35)
More information about the Haskell-Cafe