LogicJS adds logic programming to JavaScript

Russell and Norvig's AI textbook has a good introduction, although maybe it'll go into more detail than you would like. Stanford has some classes on coursera, too.

You may wish to check out the (free) books Logic, Programming and Prolog (http://www.ida.liu.se/~ulfni53/lpp/) or Learn Prolog Now! (http://learnprolognow.org).

Personally, I find declarative logic programming to be a great tool in domain analysis -- it's a powerful technique to document and prototype domain rules. I've never used it as an actual business rules engine, but I always feel like I should explore Prolog/Datalog or answer-set programming as a possible solution.

The Reasoned Schemer by Daniel P. Friedman, William E. Byrd and Oleg Kiselyov

https://mitpress.mit.edu/books/reasoned-schemer

It's from the author of miniKanren on which LogicJS is based.

There are implementations for a lot of other languages (other JS implementation too) on

http://minikanren.org/

Well, the classic logic programming language is Prolog, so learning it would be a good start. Here is something fairly lightweight on the subject:

http://www.amzi.com/AdventureInProlog/advtop.php

There was a great PDF that explained how unification and substitution of symbols worked in a concise and readable fashion, but I can't find it right now. Hm, maybe this one:

http://www.cs.ubbcluj.ro/~gabis/plf/Doc/SWI-Prolog/AnIntrodu...

If you're going ES6, why not just:

  import {solve} from 'logic'
  
  solve((x,y) => x === "mcbob" && y === "bob" || x === "bob" && y === "bill");

Yeah, the transformation itself shouldn't be bad.

Made a Babel transform real quick for this particular example:

http://astexplorer.net/#/ZT6HYai08w

I feel like that just obfuscates it. You can no longer dynamically use it, and it's completely unobvious what javascript expressions are supported or not.

For reference, Clojure's core.logic: https://gist.github.com/rm-hull/6952960 Or, from Norvig, presumably as an update to the solution he made with Lisp and Prolog, here's a Python version that doesn't use any fancy logic engine: https://gist.github.com/joyrexus/5301901

The core relation involved is one that captures the characteristics for an individual house:

    function house(position, country, color, pet, drink, cigar);

You need to define that relation by codifying the following:

a) The exclusivity rule. I.e. the fact that no two houses are the same colour, and no two owners have the same pet, and so on. You'll need to define your own "not equal" relation, the absence of which is a major issue with this library.

b) the positioning. Since this library can do arithmetic, I would just make position an integer, and do something like this:

    function left_of(pos_a, pos_b) {
        eq(logic.sub(pos_b, pos_a), 1)
    }

    function adjacent(pos_a, pos_b) {
        or(left_of(pos_a, pos_b), left_of(pos_b, pos_a))
    }

c) finally, just go in and codify all of the hints. This will probably be quite long and awkward because you'll need lots of lvars, and the conjunction relation is binary only, but it should be easy to do nonetheless.

For example:

> the Norwegian lives next to the blue house

    and(and( 
        house(pos_a, 'Norwegian', col_a, pet_a, drink_a, cigar_a),
        house(pos_b, country_b, 'Blue', pet_b, drink_b, cigar_b)),
        adjacent(pos_a, pos_b)
    )

I have this exact example in FD.js (https://github.com/srikumarks/FD.js), plus Sudoku solvers and others.

ewwww_snake_case

Actually, this is the canonical JS with prototypes. The more common style nowadays is to (ab)use the module pattern.

Looks like perfectly ordinary, old-style, prototype-based ES5 to me? Formatting is a bit idiosynchratic, of course (e.g. lines starting with comma).

Prefix operator is the Lisp notation and it has work pretty well. The syntax rule is very simple. Once got used to it, it's very easy to deal with it.

Chainable calls work well with linear operations. With nested scope, it becomes less clear.

Not at all, I think that many people have come to expect this syntax from many ORMs. You will often see syntax like:

  {
    and: [
      {or: [a, b]},
      {a: {gt: b}}
    ]
  }

Prefix operators are pretty common, actually. They have their strengths

Which style is more readable depends on whether in practice you end up with more sequence-like structures, or more tree-like structures. Chaining makes sense for sequences. For tree-like structures, they get confusing because the nesting levels aren't apparent.

For example: In your code sample, it's a bit unclear what nesting level the .and() call is occurring at. It could be a method call from the chain that starts at secondVar, or the chain that starts at firstFar. Distinguishing which one requires counting all the intervening parentheses. This okay for the given example, but gets out of hand as the conditions get complicated.

Ergonomics aside, I don't think the prefix notation is unintuitive. It's a bit verbose, since JavaScript doesn't have operator overloading, but to me it seems the most sensible and straightforward way of structuring the relationships.

Agree in essence - the code is basically saying something like "AND CONDITION1, CONDITION2" which is awful to me.

In that context, I think "any" (for "or") and "all" (for "and") make a lot more sense. E.g.

    all(first, second)

It'd read as "ALL of CONDITION1, CONDITION2". More complex combinations are also easier.

    all(any(first, second), third)

Why is such complication introduced and what are the benefits of it?

      firstVar || (secondVar=='Bob' && thirdVar==41)

seems very clear to me.

On the other hand JavaScript has always had logic operators... therefore has always been able to perform logic programming.....

From http://www.ecmascript.org/es4/spec/overview.pdf page 18

  “&&=” and ”||=” operators
     ES4 introduces assignment operators for the logical   
     “&&” and “||” operators. These assignment operators
     are short-circuiting; if the value of the left-hand- 
     side determines the value of the result then the right-     
     handside is not evaluated.

I mentioned in another comment, but there are many json structures meant for representing logical operations currently in use by ORMs (see mongoose, sequelize, loopback, etc).

+1 to seeing a standardized object structure for logical operations

Prefix notation already makes it a tree. Why would an explicit data structure tree instead of the AST make it better? Outside of being able to manipulate logic program structure at runtime.

It wouldn't be too hard to write a function to turn a tree-based structure of your design into a tree of function calls using the existing API.

Business rules systems and logic programming are definitely similar. Most business rules are based on "Forward Chaining" (https://en.wikipedia.org/wiki/Forward_chaining), basically using what we know to satisfy the left hand side condition and then using the right hand side to assert new facts. Logic programming is usually based on "Backward Chaining" (https://en.wikipedia.org/wiki/Backward_chaining), where the system attempts to work backwards from a goal to what facts are needed to satisfy the goal.

It's an entirely different concept; this is logic based programming and constraint solving, nothing to do with DOM elements or user input.

Logical constraints and CSS/DOM constraints are entirely separate things =)

*niche

Why does this need promises? Logic operations in JS doesn't do any I/O operations. Making this promises compliant is just overkill.

niche not nitch

What we have available cannot do what this does - logical resolution. The point is not the syntax for boolean operatons, it's that it can find solutions by resolving logical expressions against each other in a way that lets you say "add(2,x)=6, what is x?" and get an answer from the solver. This is basically doing Prolog using JavaScript, a thing vanilla JS is absolutely not equipped for.

There's absolutely nothing about this that would benefit from having promises - none of the operations performed are blocking. It's constraint solving, not I/O.