clara

http://www.clara-rules.org/
alex-dixon 2018-01-15T18:02:28.000474Z

@dave.dixon just curious Re part of issue 371: if you had something like s/querydef would you still want ns kw names for defquery?

sparkofreason 2018-01-15T18:05:05.000236Z

What is s/querydef?

alex-dixon 2018-01-15T18:06:06.000486Z

Doesn’t exist. 🙂 Thinking it could be like s/fdef for queries

sparkofreason 2018-01-15T18:26:51.000147Z

That's a good idea. But I'd still want keyword names. It's not a big deal, just a nice option to give more flexibility to DSL authors. I have it working in my local branch in CLJS, pretty minor change.

alex-dixon 2018-01-15T18:29:56.000453Z

What do the vars end up being named? e.g. (defquery ::some-alias/my-spec ..) => #’rule-ns/ … ?

sparkofreason 2018-01-15T18:38:27.000334Z

There are no vars. I'm not defining the queries as ns-level defs. They're grouped inside of a named object, and that symbol winds up holding the collection of productions that is provided to defsession.

👍 1
alex-dixon 2018-01-15T20:21:33.000415Z

Like most of your suggestions and changes I like that. Using defs/the ns as a kind of data structure is something I like sometimes and not others

alex-dixon 2018-01-15T20:24:17.000299Z

Is that part of your proposal? If not how would you envision this working for users of Clara? Would it affect session reloading?

sparkofreason 2018-01-15T21:28:01.000225Z

I'm putting together my own DSL that has those characteristics, not proposing to alter the existing rules DSL packaged with clara. I handle reloading in the implementation of my DSL. Since rules are just grouped in vars, it's pretty straightforward, don't have to deal with the subtleties of CLJS namespace reloading etc.