There's Mercury. I think it's a pretty good language. It's better than Lisp at least, which doesn't do anything interesting for execution power or safety besides table stakes like memory management.
There could/should be because of Answer Set Programming, which addresses one of the features of prolog that derailed it from widespread adoption. Prolog makes a committed choice as it expands it's search tree, and this can lead to surprising behaviors and failures.
Now - most Prolog folk ardently deny that and say "no these are what the language does, so that's not a point of discussion." But I will write an example and then say why this matters.
In SWI prolog (and all the other prologs I've tried) if you write a program like :
The thing is clause orders matter because the inference engine explores them in it's matching process in order and it's really really easy to introduce a killer search like this. This is also really difficult to debug and it's a bug that is very difficult to predict - in that any prolog program of a large size may suddenly manifest this behavior with no warning. You may be able to find the bug, you may not...
So - this really kills enthusiasm for prolog in commercial environments.
Answer Sets get over this - the order of the predicates is not important, the solver can cope with the massive recurrent searches. Knowledge Based Systems and deductive inference are now more possible than ever before - and we have orders of magnitude more resources to throw at them than we did.
Additionally we have mechanisms for probablistic reasoning in MCMC that we didn't before and a unified paradigm of logical programming looks like its on!
The sad bit is that not many people seem to want it - it's quite hard to think of the real problems that we will solve this way. We know that efforts like Cyc are just not going to work out, so there's no talk of "universal knowledge bases" or building common sense in.
The only technical barrier I can think of though is that programming in the large isn't really thought through in these kind of large inferencing systems - there's a unified model that essentially has to be written by one person at the heart of them. We need to have collaboration and concept formation tools and processes that work for large teams to develop scaled systems like these.
Ugh, no. SQL is a special-purpose database language. I've tried to look at Prolog from a databases point of view and it makes no sense that way. Even datalog (a decidable subset of Prolog without functions and negation) doesn't make that much sense from a databases point of view and it was specifically designed as a database language from the start, far as I can tell.
In practical terms, SQL is like one third of Prolog. Prolog programs are stored in a database as sets of Horn clauses that can be conditionally true (definite clauses or "rules"), unconditionally true (unit clauses or "facts") or unconditionally false (Horn goals, or "queries"). A Prolog program is executed by trying to refute a Horn goal by proving it false in the context of the program with an automated theorem prover and binding the variables in the goal in the process. Unit clauses correspond to database rows in SQL, so a SQL database is basically a set of "facts", seen from the Prolog point of view. But there are no "rules" and "queries" in the database - instead the program is written in an altogether different language that sits on top of the "facts" in the database. So from the point of view of Prolog, SQL is two languages only one of which bears some resemblance with Prolog.
From the point of view of SQL also, Prolog is proabably quite alien - you can write recursive loops with your database rows O.o They're just two very different languages anyway you look at them.
SQL and Prolog have a large area of functional overlap as they are both based on predicate logic. However, SQL more naturally aligned with the database-centric worldview of many business systems and offered a more natural way (for business users) to ask business questions. So when SQL took off, it was adopted for many solutions where Prolog might have been used previously.
