
Prolog Programming Language (1997) - bencevans
http://groups.engin.umd.umich.edu/CIS/course.des/cis400/prolog/prolog.html
======
jplahn
We had to use Prolog in my comparative languages class last semester and it
was interesting, to say the least. With any class that brushes over a topic, I
didn't get a full appreciation for what it can do, but it was an interesting
paradigm to be exposed to if nothing else.

I didn't feel like I was doing "real programming", which likely says more
about what we're taught than the merits of the language. I'd be interested to
known how it's being leveraged presently? I know a lot of the standard use
cases, but is there anyone solving really unique problems with it?

~~~
exDM69
I'll share an _idea_ for a logic programming project that I've been brewing
for quite some time (but never started working on)...

As you may know, the engine behind Prolog is based on the unification
algorithm (finding substitution values for variables to make two patterns
equal). The same algorithm is behind Hindley-Milner -style type inference
algorithms.

I have been considering writing a compiler for a programming language that
would do type inference indirectly in two steps. In the first step (a typical
syntax tree walk), rather than doing the actual unification directly, a Prolog
-style logic program would be emitted. In the second step, the logic program
is evaluated which will result in the types for the program.

The advantage of this approach would be allowing function overloading
(similarly to C++ or Java) informally without interfaces or type classes. This
means that there will be ambiguous types for expressions, something which is
quite hairy to implement using a H-M based classic type inference algorithm.
If the final output has ambiguous types, it is a compile error in the source
program.

This is just a crazy idea I've been brewing, but this would definitely be a
nice use case for a Prolog -style logic programming language. In practice, it
wouldn't probably be Prolog itself, because implementing similar languages is
so much fun and writing the code to call an external Prolog interpreter is
about as much trouble but a lot less fun.

Prolog certainly isn't your every day programming tool, but in some cases it's
a really good tool to have. And learning logic programming is one of those
ventures that will expand your horizons.

Finally, here's a logic programming interpreter I wrote some years ago for a
class:
[https://github.com/rikusalminen/slolog/tree/master/example](https://github.com/rikusalminen/slolog/tree/master/example)

~~~
ehamberg
> The advantage of this approach would be allowing function overloading
> (similarly to C++ or Java) informally without interfaces or type classes.

I might be misunderstanding something, but how does this allow function
overloading more than ordinary let-polymorphism? Functions can already have a
type like, say, ∀a.a→Int. It's also quite common to do type inference in two
steps where the first pass creates type variables and a list of constraints.
The set of constraints are then passed to a unification algorithm, see e.g.
[http://www.seas.upenn.edu/~cis552/lectures/stub/FunTypes.htm...](http://www.seas.upenn.edu/~cis552/lectures/stub/FunTypes.html).

~~~
exDM69
In a classic Hindley-Milner type inference algorithm, you can't have a
function "add(int, int) -> int" and "add(float, float) -> float". E.g. in
Haskell, you'd need a type class for this.

Modern functional programming languages use a type inference algorithm more
sophisticated than the original H-M algorithm which are more flexible than the
original algorithm. The link you gave as an example is Haskell with a handful
of language extensions related to the type checker - something entirely
different to the H-M algorithm.

There can be other ways of implementing a similar type checker in a different
manner, this was just a fun idea I came up with.

------
tkosan
I started learning how to program in Prolog a few years ago. I found Prolog to
be very difficult to understand, mostly because I did not understand what
symbolic logic was. I then purchased a significant number of books on symbolic
logic and started studying them. I don’t think it is possible to understand
Prolog without first understanding how symbolic logic works.

My recommendation for someone who is interested in learning how to program in
Prolog is to start by reading “Logic for Problem Solving” by Robert Kowalski:

[http://www.amazon.com/Problem-Solving-Revisited-Robert-
Kowal...](http://www.amazon.com/Problem-Solving-Revisited-Robert-
Kowalski/dp/3837036294/ref=oosr)

I am currently about halfway through an earlier edition of this book, and it
is the first book I have found that clearly explains the ideas upon which
Prolog is based.

~~~
MonkeyIsNull
This looks amazing, thanks for posting.

------
yarrel
Prolog is one of those languages that's worthwhile to learn even if you never
use it.

Try the Zebra problem, Towers of Hanoi or a family tree example to get a feel
for what it's like.

~~~
MonkeyIsNull
Not only is it worthwhile to learn, it's worthwhile to use for real world
problems:
[https://www.youtube.com/watch?v=G_eYTctGZw8](https://www.youtube.com/watch?v=G_eYTctGZw8)

From his blog: [http://blog.ndrix.com/2014/10/how-we-use-
prolog.html](http://blog.ndrix.com/2014/10/how-we-use-prolog.html)

------
JoelHobson
Are there any modern logic programming languages? I've tried looking for them
before, but found nothing.

~~~
wk_end
I can't say I've tried it myself, but Mercury looks interesting:

[http://en.wikipedia.org/wiki/Mercury_%28programming_language...](http://en.wikipedia.org/wiki/Mercury_%28programming_language%29)

[http://www.mercurylang.org/](http://www.mercurylang.org/)

------
angersock
The first time I read about Prolog, I thought to myself, "Man, this is what
computing was supposed to do for us! Look at it answering questions, doing
planning...holy cow."

And in the last 40 years? Maybe Erlang (a Prolog descendant), Ruby (maybe the
best successor to Lisp/Smalltalk), or Elixir (an Erlang descendant looks like
Ruby) is as impressive. The rest is either hacky (C++, Javascript, Perl),
attempts to clean up hackiness (Java, D, Go, Rust, Clojure), unoriginal
(Python, C#), or just plain wanky (OCaml, Haskell)--and that's not counting
ones that are beneath mention (PHP).

Don't get me wrong...there are some languages that are actually quite
beautiful in their implementation or use (Lua, Clojure, a few others), but the
"holy shit this is the future!" feeling I get from looking at Prolog, Erlang,
or Ruby is something I haven't had in a while.

Instead, the future of practical programming languages is probably going to be
yet another tepid iteration on Algol, with closures and memory safety and
incorrectly-handled numerical safety and some lame concurrency story. Pattern
matching if history is slightly kind to us, probably still no mandatory tail-
call optimization. Sigh.

Go is the future, I guess?

~~~
walterbell
What do you think of Awelon?

[https://github.com/dmbarbour/awelon/blob/master/AwelonProjec...](https://github.com/dmbarbour/awelon/blob/master/AwelonProject.md)

 _" My goal is to unify programmer experience (PX) with the user experience
(UX).

This is an elusive goal. It has been pursued for many years, with many
different hypotheses for what such a unification might entail and how it might
be achieved. Related projects include Squeak Smalltalk, ToonTalk, LambdaMOO,
Morphic, Croquet, Emacs, and HyperCard. A relatively successful effort to
unify PX and UX was the Unix command line, where users would build short
programs of process pipelines. But that has been marginalized by the
development of GUI.

To me, the unification of PX and UX means that programming becomes a casual
effort, such that users make it part of their normal workflow and don't even
think about it as programming._"

~~~
agumonkey
Weird, I read some of dmbarbour's articles from a RSS feed, but I never read
the basis for its awelon project, basis that have been an obsession of mine
for quite a while. Thanks.

