[HN Gopher] PostgreSQL-Prolog: A Prolog library to connect to Po...
       ___________________________________________________________________
        
       PostgreSQL-Prolog: A Prolog library to connect to PostgreSQL
       databases
        
       Author : triska
       Score  : 91 points
       Date   : 2021-09-26 12:04 UTC (10 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | EamonnMR wrote:
       | Very cool. I really think that prolog's future hinges on its
       | interop with sql.
        
       | infogulch wrote:
       | Wow pretty cool. The next thing it needs is query params so you
       | can avoid sql injection / unreliable user-maintained escaping
       | rules.
        
       | void_mint wrote:
       | I love Prolog and I love Postgres.
        
       | maweki wrote:
       | Prolog and side-effects are a really unfortunate pairing. What I
       | would love is when backtracking over a side-effect, that effect
       | would be taken back. With transactions that might even be
       | possible.
       | 
       | As it stands, quering (pseudocode) "connect(C), insert(C, data),
       | false" has no solution but side-effects.
       | 
       | SLD-resolution probably just does not work with side-effects.
        
         | [deleted]
        
       | TedDoesntTalk wrote:
       | Last I used prolog was about 1990 (more than 30 years ago). I'm
       | glad to see it still evolves!
        
       | hirundo wrote:
       | The Datalog query language is a subset of Prolog. I wonder how
       | hard it would be to translate Datalog into SQL and query
       | PostgreSQL with that. XTDB (aka Crux), which uses Datalog,
       | supports some limited SQL querying. How limited would it be to go
       | in the other direction?
        
         | dgb23 wrote:
         | If you're ok with typecasting then it's relatively straight
         | forward. I think postgres has some convenient utility around
         | that.
        
         | maweki wrote:
         | With recursive common table expressions it is really
         | straightforward. You just have to manually stratify your
         | datalog program to find out the order for the CTE.
         | 
         | And then you just write down all the rules.
         | 
         | edit: As long as queries aren't recursive in a difficult
         | manner, like co-recursive or have multiple recursive calls in
         | the same rule.
        
       | koeng wrote:
       | This is extremely cool and I will be testing it out. I'm building
       | large systems for handling biological data, and have wanted to
       | use prolog for that use, but couldn't fit all of my data in RAM.
       | This could help me a bunch.
        
         | triska wrote:
         | Importantly for this use case, Scryer Prolog represents lists
         | of characters very compactly internally, using a sequence of
         | raw bytes! It is the first Prolog system to use this efficient
         | representation. This helps considerably when processing huge
         | amounts of data, for example when parsing large text corpora
         | with Prolog's built-in grammar mechanism, definite clause
         | grammars (DCGs).
        
           | tannhaeuser wrote:
           | Sure about that? It is/was pretty common to keep strings as
           | long as possible, and convert to list of chars lazily only
           | when absolutely necessary.
        
             | triska wrote:
             | The key innovation of Scryer Prolog in this respect is that
             | the system _internally_ , i.e., within Rust, represents
             | each string as a sequence of raw bytes (UTF-8 encoded,
             | 0-terminated), and _to Prolog programs_ , the string
             | appears as if it were a _list_ of characters (i.e., atoms
             | of length 1). So, no conversion is necessary at all: The
             | compact internal representation is used whenever possible,
             | and Prolog programs only see lists of characters all of the
             | time, making common predicates such as append /3 and
             | length/2, and most importantly DCGs, automatically usable
             | for reasoning about strings.
             | 
             | For example, the string "abc" takes only 4 bytes in this
             | representation, and the unification "abc" = [a,b,c]
             | _succeeds_. Indeed, we have:                   ?-
             | write_canonical("abc").         '.'(a,'.'(b,'.'(c,[])))
             | true.
             | 
             | On 64-bit systems, a conventional internal representation
             | of "abc" as the compound term .(a, .(b, .(c, []))) takes 8
             | bytes per functor (each '.'/2 takes 8 bytes, i.e., 1 cell
             | in the WAM), 8 bytes per character (as a pointer to the
             | atom table, again 1 cell in the WAM), and 8 bytes for each
             | tail. All Prolog systems before Scryer Prolog use 16 to 24
             | _times_ as much memory to represent a list of characters.
             | As of recent, Trealla Prolog also uses the efficient
             | representation, at least for _fully instantiated_ strings.
             | Scryer Prolog can also represent _partial_ strings such as
             | [a,b,c|Ls] with the efficient encoding.
        
         | still_grokking wrote:
         | A little bit off-topic, but still related: I could imagine the
         | Flix language being a good fit for that use case.
         | 
         | https://flix.dev/
         | 
         | It has first-class Datalog constraints as a language feature!
         | 
         | As being a FP language it's of course good at modeling data. At
         | the same time it's fast enough for heavy tasks: It runs on the
         | JVM, having also access to its rich ecosystem.
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2021-09-26 23:01 UTC)