Fork me on GitHub
#clara
<
2018-01-15
>
alex-dixon18:01:28

@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?

sparkofreason18:01:05

What is s/querydef?

alex-dixon18:01:06

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

sparkofreason18:01:51

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-dixon18:01:56

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

sparkofreason18:01:27

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.

alex-dixon20:01:33

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-dixon20:01:17

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

sparkofreason21:01:01

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.