Introduce cond/1 support in queries

[sasikumar87]

Referring to #515, this PR introduces multi-clause select as a macro, which in-turn expand to nested Series.select/3 queries. This makes nested selects easy to write in a flat structure and improves readability.

Below are the list of assumptions made in this PR

• Each clause will be prioritised by top-down by their order of definition
• If none of the clauses match, it will be calculated to nil

Creating the PR for initial feedback, will add the docs if the approach is good.

[philss]

For me it looks amazing! 😍

But let's wait to hear from José :)

[josevalim]

You can do the reverse here, so we don't do it at runtime, and you can use tuples (semantically better):

Suggested change

	|> Enum.map(fn {:->, _, [[condition], on_true]} -> [condition, on_true] end)
	|> Enum.map(fn {:->, _, [[condition], on_true]} -> {condition, on_true} end)
	|> Enum.reverse()

[josevalim]

Something you could optimize is to check if condition == true. If that's the case, you know it will always be true and you can skip the whole select. Something like this:

  {true, truthy}, _acc -> Explorer.Shared.lazy_series!(truthy)
  {condition, truthy}, acc -> ...

[josevalim]

This is great @sasikumar87!

The only question I have is if we want to call it cond do instead of select. I would prefer to keep it closer to Elixir, so cond is my vote.

In that case, instead of defining a defmacro select(...) do, you should match on defp traverse({:cond, _meta, clauses}) do. Everything else should remain the same. The documentation would go in the module docs.

---

PS: Now that I think about it, we could also support case ... do but an initial version would require all patterns to be literals (i.e. integers or strings). But that's for another PR. :)

[sasikumar87]

The only question I have is if we want to call it cond do instead of select. I would prefer to keep it closer to Elixir, so cond is my vote.

@josevalim I read the following in #515,

We chose select do instead of cond because, opposite to cond which only evaluates the clauses that matches, queries always evaluates all clauses in order to build the expression.

Do you think this argument still has merit to use select? Personally I would prefer cond too.

[josevalim]

I see @josevalim from the past disagrees with @josevalim from the future. Let me think about it, haha.

[josevalim]

@sasikumar87 let's go with cond. Thank you!

[josevalim]

💚 💙 💜 💛 ❤️