Here's a kind of situation, from Zork-style adventure games (an early AI testbed) which makes me go 'hmm' about the current capabilities of languages like Prolog, or even Dialog.
Say you have a spellbook. The spellbook is an object and it contains spells. Each spell has a precondition (what must be true in the world), a result (what changes in the world), and a description (text and predicate calls).
Oh and you'd like the user to be able to write spells at runtime.
What you'll probably find is that you want each individual spell to have unique variables in it BUT you'd maybe not want a spell to be a 'rule' as such.
And you need to be able to examine a spell and look at its logical structure, so that the world simulator can apply its changes to the world AND a character's goal-planner can ALSO theorise about what the result of casting a spell might be.
But the spells aren't necessarily known at compile time.
Kanren is probably better at this sort of thing than Prolog is, because it has the 'fresh' operator which you can use to create new clauses containing variables at runtime.
It *might* be okay for 'clauses containing fresh variables' to always have to be a 'rule'. Maybe. But we'd maybe sort of like them to just be kind of objects?
That's because Infocom's 1970s-era virtual machine technology wasn't very good at this sort of runtime-modifiable thing. Mostly because it was optimised for space on tiny machines.
Which was fine for 1979 BUT we probably shouldn't still be living with 64K RAM kind of limitations in 2021.
But think of something like Spellbreaker's white cubes that you could name yourself at runtime, and then extend that to being able to parse arbitrary text and compose arbitrary spells.
Dialog will let you set *some* facts at runtime (if you're in debug mode), but you can't create new rules, because compiled language and optimised for a 64K 1979-era Z-machine.
You *might* find it a little awkward to emulate the whole Prolog variable-binding mechanism in a runtime-interpreted domain-specific language in a Prolog, though. It's not quite as easy to do as in a Lisp with an eval.
Eg imagine if it's not just "a spellbook of spells", but it's an entire MUD, and you want the users to be able to define arbitrary commands at runtime.
Of course "just eval" isn't the answer either because of security, but something *like* eval.
But mostly, I'd like to be passing around runtime data structures representing arbitrary human knowledge (as generated from, eg, parsing natural language) and it feels like such knowledge invariably contains something *like* variables or function applications. How to handle that in a simple, clean, safe, and intuitive manner is the main problem, really.
Both "just create a tottering tower of domain-specific languages each separately implementing a different fragment of Lisp/Prolog" and "disallow handling that kind of knowledge as runtime data, it's far too dangerous / ill-formed / not strictly typed / unsafe / nonterminating" seem like insufficient answers to the general problem.
The sort of thing I want to represent is something roughly like "X believes/asserts that: Y if Z" and it seems like this sort of small chunk of parameterized knowledge ought to be *reasonably* safe to think about, if we nailed down things like variable references, environments, etc a bit more strictly than Prolog does.
For my thing, you'd write it in Ruby and import it, possibly as an extension to the DSL. That's the advantage of this approach: you can use the full Ruby language if you need it, unlike dedicated languages.
Also: IF and MUDs are dramatically different things and have completely different sweet spots. IF optimizes for a developer shipping a deliverable while MUDs are collaborative development environments.
If I were writing a MUD from scratch today, I'd use one of the existing sandboxable extension languages (Tcl, Lua, maybe MRuby, Python?) and just let users hook scripts to objects. The 90s MUDs used homegrown languages with all of their quirks but these days a Real Language as a library is a common thing.
And these are all powerful enough to implement a Prolog-style unification engine or provide an interface to a native-code one if needed.
"IF and MUDs are dramatically different things and have completely different sweet spots"
It would certainly be logical to think that given those subgenres' separate histories, and yet, ten years ago there existed a MUD based on Inform 7 (in all its baroque natural-language glory).
Gnusto, I think it was called?
So what I guess I'm saying is, sometimes history isn't destiny.
Except that it kind of failed due to lack of interest, but as a tech demo it worked, sort of.
But it worked by including the whole Inform 7 editor / compiler / VM toolchain, so it was kinda like a cloud host for Z-machines. It's certainly possible to do anything if you stack up enough layers, but what I want is to *remove some of the layers that are already stacked up*. "Types" vs "functions" being two of those layers.
But I can see I'm wearing out my welcome on this topic so I'll shut up for a few more decades now, or until I have something to demonstrate.
Well the closest I can get you to it at this point is "Planner for Dialog"
which is long overdue a rewrite/expansion but I got distracted, as always happens.
But with this at least you can do the spellbook (not implemented, I must get around to doing that), but if you wanted to have the user creating new spells at runtime, you'd need to have a whole bunch of indirection through lists. (Lists are the only runtime-creatable structured object Dialog offers).
My explorations around Planner and its ancestors (going back to around 1997) are the main motivation for my grumpiness with the state of the art in logic programming.
There's just so much double-handling you have to do, for AI in games, to code up runtime-readable representations of things already defined by the world-simulation code. Dialog being a Prolog makes querying the world rules *much* nicer, and reduces much of this drudgery. But it's still not 100% where it should be.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!