Clojurians Log v2

@seancorfield have you thought about using also symbols, lists to help disambiguate stuff?

Eg a function call could be a list, or the name of the function could be a symbol

@orestis To be honest, that would make a lot of the code more complex, and it would make the documentation more complex.

There are a handful of places where the condition is "`keyword?` or ..." right now but actually in most places (in V2) keywords and symbols are accepted equally and I just have to decide whether that's useful to document or not.

Operators and functions have to be keywords right now in V2. And both :on-conflict and :do-update-set which I implemented today currently expect keywords. But everywhere else symbols would actually be accepted everywhere keywords are. Disambiguating function names via keyword vs symbol doesn't actually help anything.

Well, it would help in that one limited place in a :select where you wanted to tell the difference between a function call and an alias but I've already disambiguated that (by requiring the function call be nested).

I don't think that one case is worth the extra confusion/complexity.

As it is, I'll probably allow symbols anywhere a keyword could be used, just because it's pretty trivial to do, although I don't think it makes anything substantially easier to write the DSL.

The only thing that symbols have over keywords is the datalog-style, quote-the-whole-expression approach.

Which I think is why I was banging on about named parameters the other day - because quoting the whole expression means you can’t easily pull in values from locals and vars, therefore you need to do the substitution later.

But, I think that having a specced honeysql data structure means that ergonomic layers such as the one I describe could be done elsewhere.

So I think your litmus test of “does it make the implementation simple” is the correct one :)

@orestis Ah, OK, now I get where you're coming from. Yeah, if I make symbols universally acceptable wherever keywords are accepted, then you could do that (and, to be honest, it doesn't make much difference really on the backend since I'll just add a predicate that tests keyword-or-symbol? (If I make Clojure 1.9 the base version supported, I'll just use ident? 🙂 ). But a lot of people construct queries dynamically so it wouldn't help there. But, yes, named parameters will be coming to 2.x -- I've come up with a clean way to implement that without making the SQL generation engine any more complex.