Prolog isn't dead, it just doesn't seem to get a whole lot of attention these days. I use SWI-Prolog for prototyping and exploratory programming, and I didn't need a shovel and a lantern to install it.
I don't think Prolog is practical as a fully standalone language, though. Like SQL, it has a model that strongly skews it towards certain kinds of problems, and which makes I/O and side effects awkward. I think it would be best to have a Prolog-like language as a library (like Lua or SQLite), to embed it for rules & scripting. (Writing one is on my project TODO list. I've been reading quite a bit about Prolog implementation.)
To me, the single most interesting aspect of Prolog is computing with partial information via logic variables: variables that are constant, but don't necessarily have to be bound immediately. Conceptually, the variables always have some specific value, but you didn't know until they were bound. You can pass around structures with holes in them to use as templates in pattern matching, append lists by binding the "hole" at the end of a list to another's head ("difference lists"), etc., while still keeping the advantages of immutability. Most languages descended from Prolog (Mercury, Erlang) drop logic variables, though Oz keeps them.
Another kind of computing with partial information is constraint programming, which makes Prolog much, much less dumb. Generate-and-test is great for prototyping, but quickly shows its limits with combinatorial problems - where constraint programming excels. Most major Prolog implementations come with constraint programming extensions, and they address many of its weak points.
There's also Erlang. Erlang seems like a very modern, practical evolution of the declarative + concurrent direction that some logic programming research was going. If you remove backtracking (which makes handling concurrency far more difficult), then I/O also becomes feasible. Erlang keeps much of Prolog's declarative-ness, and adds several powerful features of its own.
Re: Prolog implementation, in case you haven't already found it, the book Warren's Abstract Machine: A Tutorial Reconstruction, by Hassan Aït-Kaci, is pure gold for understanding the WAM.
Yes - I have a printed copy of that, actually. It's not the end of Prolog evolution, but it's a good snapshot of common implementation techniques, and it definitely clarified things.
Perl isn't really my thing* , but I'll take a look at how they're implemented. I was thinking a C library with a C API that will make it easy to use from Lua, Python, Ruby, etc.
Yaswi is probably just a wrapper to SWI-Prolog. There are a few of those, and I'm tempted to write one for Lua.
I think designing a Prolog-like language primarily for embedding, rather than wrapping a standalone Prolog, will have an interesting effect on the design though - Lua, for example, benefits tremendously from being able to leave certain issues to C. An embedded logic language could likewise focus on what it does best.
* Somebody is probably going to pop out of the woodwork and say that my impression of Perl is based on Perl 10 years ago. They're right, as that's roughly when I switched to Python. It'd be tough to convince me to switch back, though. I'm fine with awk for "tiny Perl script" hacks, and prefer other languages for larger stuff.
It's a quick-and-dirty implementation of a Prolog interpreter, but it's a great resource for prototyping. JavaScript ports very well to Lua, so you should be able to port the code in a busy afternoon.
I made a couple of suggestions to increase the speed of the interpretation, but I'm not sure Jan ever integrated them into the code. The big one was using a trace to destructively modify environments rather than recreating them on choice points; WAM and tabling would be great, but it's a non-trivial piece of work following Warren's tech report, even with the help of the (very good) tutorial.
I'm planning on doing a C VM-based implementation with tabling* . I'm not sure about coroutines, and the VM will not necessarily follow the WAM design verbatim - Peter Van Roy has several suggestions for improvements in his thesis.
If it's implemented in C with a simple API, it should be easy to use from anything that has a C FFI. I'd rather not make it too language-specific - there's a huge duplication of effort as new languages appear.
Lua and SQLite are both great examples of libraries whose APIs make them straightforward to embed in other languages.
I've got that book, too. :) (And I recommend it to people all the time...)
I'm thinking something like Lua's C API, both because I know it well and because its design does a particularly good job of bridging C and a dynamically-typed language.
I don't think Prolog is practical as a fully standalone language, though. Like SQL, it has a model that strongly skews it towards certain kinds of problems, and which makes I/O and side effects awkward. I think it would be best to have a Prolog-like language as a library (like Lua or SQLite), to embed it for rules & scripting. (Writing one is on my project TODO list. I've been reading quite a bit about Prolog implementation.)
To me, the single most interesting aspect of Prolog is computing with partial information via logic variables: variables that are constant, but don't necessarily have to be bound immediately. Conceptually, the variables always have some specific value, but you didn't know until they were bound. You can pass around structures with holes in them to use as templates in pattern matching, append lists by binding the "hole" at the end of a list to another's head ("difference lists"), etc., while still keeping the advantages of immutability. Most languages descended from Prolog (Mercury, Erlang) drop logic variables, though Oz keeps them.
Another kind of computing with partial information is constraint programming, which makes Prolog much, much less dumb. Generate-and-test is great for prototyping, but quickly shows its limits with combinatorial problems - where constraint programming excels. Most major Prolog implementations come with constraint programming extensions, and they address many of its weak points.
There's also Erlang. Erlang seems like a very modern, practical evolution of the declarative + concurrent direction that some logic programming research was going. If you remove backtracking (which makes handling concurrency far more difficult), then I/O also becomes feasible. Erlang keeps much of Prolog's declarative-ness, and adds several powerful features of its own.