HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
logpy
logpy
Python2016–2019
logpy / logpy

logpy

Logic Programming in Python

6Distinct people
8Mentions
0Explicit recommenders
938GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Logic Programming in Python

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2016-03-24 07:08:27 UTC to 2019-05-04 11:31:11 UTC.

012342016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC422
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101

What Hacker News says

8 sources
> I wouldn't be surprised if the whole struggle to create a Python implementation was necessary to get a clear enough picture of how it all comes together, which is why it then was so easy to re-implement it in a much fewer lines of code. There was definitely some of that, but much less than you might think. The timeframe I'm talking about is a bit longer: a friend of mine tried to interest me in Prolog twenty years ago and the "penny has dropped" only now. Better late than never. But I estimate I may have wasted, outright wasted, three to five man-years of work. (I spend a lot of waking hour on programming, a lot.) The impact of the realization is so severe that I've coined a new personal rule (the first in over a decade) to wit: Always use the highest-level language/system and only "drop-down" to a lesser paradigm if I absolutely h
Read the rest
ave to (for efficiency or expressiveness.) (The paradigm hierarchy being: Logical/Relational >= Functional >= Imperative) I find myself pivoting from being an expert Python programmer to a tyro Prolog programmer. It's disorienting, exciting, it makes me giddy at moments. I'm already more productive, and it's easier to write bug-free code. In the particular case of implementing Joy in Python and in Prolog, I had previously learned about Logic Programing and Unification by studying an implementation of miniKanren in Python[1], so I knew what I was doing when implementing the type inference. There even came a moment when I realized that I should reimplement in Kanren or Prolog if I wanted to do things like propagate constraints ("value types", etc...) Then a link here on HN to "Logic Programming and Compiler Writing" by David H. D. Warren[2] finally pushed me to do it. I was in the middle of writing a compiler (to Python/Cython) for Joy and I realized that Warren's paper showed a better way. Reimplementing Joy in Prolog was as simple as typing in descriptions of the basic relations, which are then already executable. Something curious happened next. I went to reimplement the type inference code and when I had finished I realized that I had just reimplemented the interpreter. In other words, in Prolog, the interpreter and the type inferencer are the same thing. (Also, ten pages of Python code became one page of Prolog.) [1] https://github.com/logpy/logpy [2] https://news.ycombinator.com/item?id=17674859
In Factor: An impressive stack-based language environment
> What makes you think that? Direct observation. I learned unification algorithm from studying Matthew Rocklin's Python Kanren implementation [1]. The next time I was thinking out the solution of a programming problem, as I was witnessing my brain (or mind if you prefer) solve the problem, I realized on a "meta-track" that what it was doing was exactly unification. I actually "saw" it happening and had a context to recognize and name it. I think it helped that I was working in a domain that has models very close to the forms (computer programming) but the rational logical thinking process is the unification algorithm. > I don't think we have a clear idea of what the brain does when doing "intelligent" things Well, I don't mean to suggest that rational thinking is the only kind of thinking! I'm just pointing out that it's a kind of thi
Read the rest
nking that really has been automated. It's AI. (Not all that AI is or ever will be, but it counts.) Turing essentially made concrete the thought process of solving (some kinds of) math problems, noticed that the "atomic elements" of the process were a finite set, and designed a machine to automate those steps, so in a sense, computers have always been AI. > CLP(FD) stuff you posted isn't "just" unification, it needs additional powerful constraint solving algorithms behind it to work as well as it does. Yes, and the brain has powerful sensory systems attached to it. I think science has identified something like twenty-seven different human senses. These all supply "finite domains" to the reasoning system. The sensory systems are very active, and can function in "virtual" mode (aka imagination) to permit a kind of thinking by simulation (analogs.) Animals have this sort of thinking as well (that's why they can dream.) The linguistic/digital system reifies this fast primary mode thinking into slower rational thinking distinctions and reasoning, which is then used to build coherent models of the world which are then used to generate behavior. [2] If you codify that thinking process you get the unification algorithm. [1] https://github.com/logpy/logpy [2] ...and behavior generates new sensory inputs... The whole thing constitutes a feedback loop linking the real world with your subjective experience. Linguistic thinking permits direct modeling of recursion, which permits thinking about open-ended loops in behavior in a concrete way, which permits self-referential modification of the reasoning structures, enabling rapid innovation in behavior (aka "culture".) You're a cybernetic process that can become a Gödel machine.
In The Power of Prolog
That's very kind of you. Your comment made my day! :-) I came to Logic Programming via grokking mrocklin's port of Kanren to Python: https://github.com/logpy/logpy; and to solving logic puzzles via Laws of Form: http://www.markability.net/ (Last year the author of that site George Burnett-Stuart apparently cracked how to encode Predicate Calculus in the notation, which is an exciting development, IMHO!) So I'm not a complete novice. That said, at first I thought I should define relations like smokes and pet_of, but somehow between seeing the table on the Wikipedia entry for the Zebra Puzzle and the SEND MORE MONEY example (https://github.com/triska/clpfd/blob/master/sendmory.pl) it became obvious what to do. If you look at the SEND MORE MONEY solution you'll see the Zebra solution is laid out just like it. To me, it seems like the
Read the rest
same sort of puzzle as Sudoku, but much simpler. It's unfortunate that the solution and the solving proper (querying for the result) obscure the art of the puzzle-maker, eh? Thanks for the suggestion! I've incorporated it into the version in Github "gist": https://gist.github.com/calroc/603ed919bc814ccee10c1b3df6142... (I kept the more verbose query though, as I think the output is nicer. :-) YMMV)
In The Power of Prolog
If you find this kind of thing interesting, there is actually a branch of computer science called "logic programming" that is very similar, but actually useful for practical applications (as it's not a joke). A really simple example would be something like logpy [1]. You give it a set of variables, and a set of constraints, and it will try to efficiently solve for values that meet all the constraints. A more professional-grade logic solver might be Clojure's core.logic [2], which has been used in many real-world applications. Compare the core.logic Sudoku solver [3] with the quantum version. They are similar, in that they each set the constraints for a solved board, but core.logic is vastly, vastly more efficient. [1] https://github.com/logpy/logpy [2] https://github.com/swannodette/logic-tutorial [3] https://gist.github.com/swannodette/3
Read the rest
In Show HN: Quantum suicide in Python

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.