←back to thread

Clolog

(github.com)
258 points todsacerdoti | 1 comments | 15 Apr 25 17:04 UTC | HN request time: 0.335s | source
Show context
sterlind ◴[15 Apr 25 17:41 UTC] No.43696088[source]▶
really happy to see something of a revival of interest for logic programming lately. it's an extremely powerful tool if you know when to reach for it.
replies(2): >>43696328 #>>43696926 #
MarkMarine ◴[15 Apr 25 17:59 UTC] No.43696328[source]▶
When would you reach for it?
replies(3): >>43696697 #>>43696708 #>>43696837 #
iLemming ◴[15 Apr 25 18:31 UTC] No.43696708[source]▶
Scheduling, e.g., course scheduling - allocating rooms, professors, time slots while satisfying constraints; Product configuration systems - helping customers select compatible options for complex products; Genealogical research - querying family relationships and ancestry; Static analysis tools for code - finding bugs or verifying properties without execution; Medical diagnosis systems - inferring conditions from symptoms based on medical knowledge; Travel planning - finding optimal routes with multiple constraints; Legal reasoning systems - determining applicability of laws to specific cases; Natural language interfaces - parsing questions and generating appropriate database queries; Hardware verification - proving correctness of circuit designs; Puzzle solvers - Sudoku, crosswords, logic puzzles;

Basically anything that excels when declarative specification of relationships is more natural than imperative algorithms.

replies(3): >>43697181 #>>43697768 #>>43703416 #
whartung ◴[15 Apr 25 20:08 UTC] No.43697768[source]▶
Well the bigger question is how big does the system have to be to warrant breaking out a new technique, much less adding a new runtime or other large dependency.

Now, I have no direct experience with any of the common logical programming systems. I have familiarity.

But anytime I came upon anything that might justify such a system, the need just didn’t seem to justify it.

Talking less than 100 rules. Most likely less than a couple dozen. Stacking some IFs and a bit of math, strategically grouped in a couple aptly named wrapper methods to help reduce the cognitive load, and it’s all worked pretty well.

And, granted, if I had solid experience using these systems, onboarding cost would be lower.

When have you found it to be worth cutting over?

replies(3): >>43698127 #>>43700439 #>>43703919 #
1. sterlind ◴[16 Apr 25 01:29 UTC] No.43700439[source]▶
I had the (self-inflicted) problem of modeling systems of linear equations in C#. `x` is a Sym, `x+2` is an Expr, `[2x,3y]` is a TermVector, etc. I wanted the comforts of NumPy, so adding an Int to a SymVector should make an ExprVector by broadcast, you should be able to multiply two IntMatrixes together but not two SymMatrixes (since that's not linear), etc. It would have been a lot of wrapper code to write.

Instead, I implemented a minimal set of primitives, and wrote a set of derivation rules (e.g. "if you have X+Y, and Y supports negation, you can derive X-Y by X+(-Y)"), and constraints (operator overloads mustn't have ambiguous signatures, no cycles allowed in the call tree), and set up a code generator.

250 lines of Prolog, plus another 250 of ASP (a dialect of Prolog), and I had a code synthesizer.

it was one of the most magical experiences of my entire career. I'd write an optimized version of a function, rerun synthesis and it would use it everywhere it could. I'd add new types and operators and it'd instantly plumb them through. seeing code synthesis dance for you feels amazingly liberating. it's like the opposite of technical debt.