pyswip
mercury
| pyswip | mercury | |
|---|---|---|
| 5 | 2 | |
| 444 | 876 | |
| - | 1.4% | |
| 0.0 | 9.8 | |
| 5 months ago | 2 days ago | |
| Python | Mercury | |
| MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pyswip
- Find Legal Moves in Brass Birmingham with Datalog
-
Prolog at work
You're looking for PySwip.
- The Power of Prolog
-
Small Prologs engine for app
you might like https://github.com/yuce/pyswip
-
Why Learn Prolog in 2021?
It might be easier to learn prolog, if it's wrapped in more familiar python.[1] Prolog's value lies in its database core. But much of the cost of learning a language is elsewhere, in coping with yet another way to do familiar things. With prolog, these are both relatively uninteresting, and nicely separable.
[1] https://github.com/yuce/pyswip
mercury
-
Term for translating between enum switch vs map lookup?
The Mercury compiler uses all of these techniques and more. Start here in the source code, and read the comments: https://github.com/Mercury-Language/mercury/blob/master/compiler/switch_gen.m
-
Why Learn Prolog in 2021?
I'm not convinced there's great utility in smart contracts, but if there is, I think there's a huge utility in contracts being declarative and statically typed, to avoid many of the problems we've seen with existing contracts. In that case, a statically typed Prolog dialect would be a good starting point. The contract would be a set of declarative rules describing acceptable next states of the contract. To make the contracts verifiable in linear time, the submitter would submit the next state of the contract, plus a compact binary representation of the path taken through the rules set, so no backtracking would occur in the verifier. You could allow recursion, as verification time would still be linear in the size of the submitted compact path representation, just not linear in the size of the contract. If you disallow recursion, then verification would also be linear in the size of the contract.
Granted, many of the problems with Ethereum Solidity contracts are more to do with all of its use of implicit behavior (in a misguided attempt to hide the complexity of contracts) rather than directly consequences of Solidity being imperative.
Here's a quick plug for Mercury[0], a statically typed dialect of Prolog with an optimizing native code compiler. Supposedly it's 5 to 10 times faster than commercial Prolog compilers or available interpreters.
[0] https://github.com/Mercury-Language/mercury
What are some alternatives?
the-power-of-prolog - Introduction to modern Prolog
awesome-prolog - Curated list of Prolog packages and resources
trealla - A compact, efficient Prolog interpreter written in plain-old C.
Searching-In-An-Infinite-Space-Prolog - PP2014 Prolog Homework
core.logic - A logic programming library for Clojure & ClojureScript
hatlog - custom type systems for python in prolog: http://alehander42.me/prolog_type_systems
swiplserver - Python library for using SWI Prolog
clojure-graph-resources - A curated list of Clojure resources for dealing with graph-like data.
debug_adapter - Debug Adapter Protocol (DAP) implementation for SWI-Prolog
lira - Lira is a declarative domain-specific language designed to be the backbone of financial contracts that can be executed on the blockchain