Open CMCDragonkai opened 9 years ago
Perhaps something like creating C extensions?
Or shell out?
Or IPC?
Consider if the rules engine needs to interact with state. State that is held elsewhere, then it would need data access requirements.
Instead, make the rules engine ask questions. You can pass it data, but it will return asking questions. Depending on these questions, the asker needs to supply answers, so the rules engine can finish. It needs a somewhat chatty IPC technique.
Should a rules engine take rules as its own language, or use a schema language?
This would require a bidirectional messaging protocol. Both client and server need to use one socket or 2 sockets and send and receive on them.
Something like:
Process -> start session (initial)
<- response (ok) (response)
<- question 1 (initial)
-> answer 1 (response)
<- question 2
-> answer 2
<- done, with success/errors
-> ack (finish session)
Options include socketpair, ZMQ pair, Capnproto bidirectional RPC,
Doing this requires either non-blocking IO or using 2 lightweight threads one to send and one to receive, but then cross thread communication.
Erlang is another options.
Erlog looks like something that can embed Prolog as an erlang process. Then the erlang program will need to communicate to external clients using a chatty protocol like socketpair.
https://github.com/rvirding/erlog
Who knew bidirectional IPC was so hard?
The verification server needs to send questions to the client to answer.
See these:
An alternative to using logic languages and schema is to use Schema in Clojure: https://github.com/Prismatic/schema
This like distributed or outsourced dependent type checking. Outsource your dependent types to verify!
We should write this in Mercury.
Should it be embeddable?