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.

· · Web · 3 · 2 · 2

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?

I think what I'm maybe getting at is that some kind of "copy a term but with a new substitution environment for any variables in it" primitive might be more useful than a hard "rule vs fact" distinction.


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.

@natecull @djsundog

Y’know, I have about half of an IF Ruby DSL in my personal gitforge. That’d do arbitrary spells just fine.

@suetanvil @djsundog

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.

@suetanvil @djsundog

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.

@suetanvil @djsundog

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.

@suetanvil @djsundog

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.

@natecull @djsundog

So now I want to try doing this in a Ruby DSL just to prove it can be done. Since I'm working right now, there's a good chance that the urge will pass before I get started.

@natecull @djsundog

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.


@natecull @djsundog

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.

@suetanvil @djsundog

"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.

@suetanvil @djsundog

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.

@suetanvil @djsundog

Not Gnusto. Guncho.

It's an example of what's possible, but also of how big the gap can be between *possible* vs *beautiful*.

@djsundog @natecull

Fun fact: I went to university with Stephen White, the original author of MOO. While there, he wrote a followup called CoolMUD which he set running on the Computer Science Club's little SPARC server, where my first mildly ambitious object consistently crashed the server.

@natecull From the other side of the fence; the RPG trying to be a programming language ...

"...[a] system to make use of a comprehensive
magical language to tie together all aspects of magic in a gaming


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.

Sign in to participate in the conversation

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!