Huh, power of #prolog .

I need to find all leaves (interfaces) of a digraph (of entities).

That's 8 lines of Prolog:

next_entity(Eid, EidNext) :-
pad(Pid, Eid, source, _, _),
link(_, Pid, PidSink, _),
pad(PidSink, EidNext, sink, _, _).

next_interface(Eid, Iid) :-
interfacelink(_, Iid, Eid, _).
next_interface(Eid, Iid) :-
next_entity(Eid, EidNext), interfacelink(_, Iid, EidNext, _).

Before I integrated Prolog into #libobscura, I spent 2 hours trying.

#coding

@dcz Yes, prolog is powerful... but I'm not sure I want to see it embedded anywhere. That's third language in the project, and uncommon one, too :-(.

@pavel GLSL, Rust, Prolog. I think it resembles a game engine now: an engine language, a scripting language and a shader language.

I did try using rust-gpu once, but its build story was rather bad.

But looking at it from a different side, I intend Prolog to be a replacement for configuration files, which are also a domain-specific language and present in pretty much every project.

Well, if it doesn't work, it gets thrown out.

@pavel Thinking about it a bit more, the first time I wanted a serious solver was when I messed with storing programs on an arm microcontroller with special alignment requirements.

That was awkward to code in Python, so I replaced the entire thing with Z3 and added my adjustments.

I think we as an industry underutilize general solvers and I want to check this hypothesis with the Prolog experiment.

@dcz So... solver may be good idea, but it should be possible do that with Lua. I know prolog, but it is not "traditional" language and using it for all configuration is "interesting".

@pavel Lua is not a general purpose solver though, it still bases on algorighmic programming rather than defining constraints. I wouldn't call it the right tool for any job that calls for a solver.
I admit that there's a tension between choosing a tool that does a job well and a tool people are familiar with. I'd like this class of tool to be more widespread, so trying it is the least I can do.