clara

http://www.clara-rules.org/
eraserhd 2019-02-19T22:04:08.003500Z

Over the next week or so, we're going to be working on a library to translate pull expressions into Clara rules productions. Any thoughts on that now could shape how this works.

eraserhd 2019-02-20T13:55:19.000100Z

@adam622 the problem with a hand-coded dependency graph is that the tasks are sort of "locally owned" by different teams. This project coordinates tasks across the org.

👍 1
eraserhd 2019-02-20T13:57:19.000300Z

eql looks really neat, definitely something to investigate

dominicm 2019-02-20T14:00:05.000500Z

@eraserhd are you familiar with terraform at all? would you say your tool is similar?

eraserhd 2019-02-20T14:04:48.000700Z

I am familiar, we use it. I have big rants on terraform. Our thing is much higher level.

eraserhd 2019-02-20T14:07:05.000900Z

Our thing's tasks are like, "we need a marketing site". That integration might use terraform.

eraserhd 2019-02-20T14:08:40.002300Z

There's some similarities, except that we really lean on forward-chaining rules. We need to have things built as early as possible, and we incrementally discover the information we need to do things.

eraserhd 2019-02-20T14:09:30.002900Z

A terraform-like thing using Clara would be nice!

dominicm 2019-02-20T14:29:52.006Z

I want to write a terraform like thing in clojure. So I may look closer at what you're saying here.

adamfeldman 2019-02-20T14:33:16.000400Z

@dominicm Pulumi uses Terraform under the hood (and therefore takes advantage of the existing Terraform ecosystem), perhaps adapting Pulumi to Clojure would be a reasonable route to take https://github.com/pulumi/pulumi, https://github.com/pulumi/pulumi-terraform

dominicm 2019-02-20T14:34:30.001300Z

Interesting, will take a look

👍 1
dominicm 2019-02-20T14:37:51.001400Z

@eraserhd we probably share complaints about terraform, and also the level at which you are describing things sounds similar to a project I tried to tackle things.

eraserhd 2019-02-20T14:40:10.001500Z

My main complaint is that it is trying to be declarative. I think that's a mistake in that domain. We frequently need one object per thing in some database, for example, and that leads to terrible duplication and weird text ETL procedures.

eraserhd 2019-02-20T14:41:00.001700Z

Those ETL procedures defeat the idea of what terraform is for. So they've added things like loops and getting external data, but it is kind of terrible and they don't want you to use it.

dominicm 2019-02-20T14:41:03.001900Z

Oh I know. And the modules don't even help! Count doesn't even work for the "loop construct" in a number of cases, so you have to take explicit counts for everything

eraserhd 2019-02-20T14:41:08.002100Z

In reality, it should be pure functional.

eraserhd 2019-02-20T14:41:39.002400Z

right?!

dominicm 2019-02-20T14:41:56.002700Z

The terraform language sucks, generally. I'd love it if they had a minimal extensible core.

dominicm 2019-02-20T14:42:16.003400Z

I quite like the idea of figuring out some primitives for building your own tf :)

eraserhd 2019-02-20T14:44:03.004100Z

In Clojure, terraform really just becomes a data structure and a plan/apply procedure. The data structure can be generated by a function.

eraserhd 2019-02-20T14:44:32.004700Z

I mean, Clara is probably good here :D But not necessary.

eraserhd 2019-02-20T14:46:02.006700Z

The data structure needs some kind of ?var to bind results of some operations to inputs of others. Unlike the go people, we know about proper unification :D

dominicm 2019-02-20T14:47:41.007100Z

So, I'm looking at clara to do the dependency graph of work semi-automatically. For example, when do you go fetch the list of GitHub users? Well, if something wants to query them (and then you cache it). If you've diffed the list of users, and something inserts a new user, then you need to change your actions based on that. This is a pretty half-baked idea though 🙂

eraserhd 2019-02-20T14:50:42.007300Z

So, are you using it ahead-of-time to build a plan? Or are you using it during execution?

dominicm 2019-02-20T15:00:33.007500Z

execution

dominicm 2019-02-20T15:01:10.007700Z

thinking about trade-offs, I decided that a plan is possible to do as an auxiliary based on a secondary set of rules which inform you of the "optimistic write output" of a task.

eraserhd 2019-02-19T22:05:55.004700Z

We're thinking about depending on clara_eav, since this will need a triplet type, and I'm considering the EAV record in clara_eav the "canonical triplet type" for Clara.

eraserhd 2019-02-19T22:06:16.005Z

It'll likely use nothing else from it, though.

dominicm 2019-02-19T22:33:06.005100Z

Why do you need this? I'm missing something I think

eraserhd 2019-02-19T23:00:39.005300Z

The primary system I work on models tasks and data dependencies. Inputs and output for a task are described as pull expressions, and this allows us to compute task dependencies. We couldn't do this with raw Clara queries, since they model general computation so halting problem yada yada.

eraserhd 2019-02-19T23:01:14.005500Z

Pull expressions are a really nice, natural way to describe the shape of data wanted, IMHO.

eraserhd 2019-02-19T23:03:05.005700Z

We are moving to Clara handling more of the computation, because its truth maintenance property solves a lot of problem for us, and one of the new things we want to know is when a tasks inputs have changed, in order to retrigger our task.

eraserhd 2019-02-19T23:04:25.005900Z

So we're building this library to have Clara compute the inputs for a task in real time and update them as new data arrives.