Clojurians Log v2

That is excellent, thank you so much

=)

So I’m inclined to get a 0.10.0 release out today

With #149 reverted?

there’s some discussion about function application on the mailing list and I’d like to work on that but maybe in the release after that

yeah

:thumbsup::skin-tone-2:

I agree that the status quo (prior to #149) is confusing but I'm not sure whether we can agree on a fix that doesn't break existing code -- and #149 clearly breaks existing code so, whilst it solves some problems, it introduces others.

yep

the only thing I can think of that might be an improvement is treating lists as function calls

but then people wind up quoting things and that gets messy fast

I was a bit surprised at the use of tuples, to be honest. Is that standard SQL or a vendor extension?

oh hmm that’s a good question

I basically assumed it was a thing because Igor was doing it

I'd never seen it before -- but my SQL skills are not that extensive.

Bing seems to indicate it's Postgres/Oracle specific...

SQL Server, SQLite, and MySQL don't seem to support it, from what I can find.

Although ANSI SQL supposedly supports tuples as row constructors?

huh, interesting

Further reading suggests maybe MySQL does support tuple comparisons... I might have to try that...

so if it’s not standard SQL — honestly it might make sense for vectors to be reserved for function application then

MySQL supports it. TIL.

I guess it depends on how comfortable we would be breaking tuple comparison (in all cases) in order to support consistent function application? And then require, say, lists for tuples since they are much more rare than function application?

yeah

(that path would essentially reinstate #149 as a deliberate breaking change -- and document it that way)

tuple comparison can also be compiled to “where foo=bar and baz=qux” and we could provide helpers to more easily generate that if that’s helpful

(all-equal [:foo :bar :baz] [1 2 3]) or something

…if we were going to go that route I would not want to release 0.10 with #149 reverted, that would just be confusing

I’d feel a little bad since I said in the issue I was going to do that

select * from thing where (col1, col2) < (val1, val2) is valid but I'm not sure mapping that to ...where col1 op val1 and col2 op val2 is going to be correct in the general case?

huh, (col1, col2) < (val1, val2) compares in some priority order?

I wouldn’t have expected that to be valid but I guess it makes sense

so (50,100) < (100,50) since 50 < 100

(I just tested that in MySQL and, yup, that's the case)

thanks =)

yeah I think if I were doing it from scratch I’d reserve vectors for application and have a helper for tuples

where we’re at I’m not sure whether it’s worth the breaking change

There's definitely arguments on either side. There's a strong case for "tuples worked by accident because we didn't design for them, but function application not working in a value position was a bug -- and #149 fixed that, so now we're introducing a new notation for tuples..." but there's also a strong case for backward compatibility (as a general principle).

yeah

we aren’t at 1.0 yet

which I think means there should be less expectation of backward compatibility/“bug-for-bug” compatibility

I guess... poll the community to see how many people are using tuples?