predicate should accept a list of booleans

[kindlychung]

The current syntax is:

<predicate>(<variable> IN <list> WHERE <condition>)

Which can lead to bizzar statements like:

return any(n in [true] where n)
match (p:player) return p.age > 35 as senior | return collect($-.senior) as seniorList  | return any(n in $-.seniorList where n)

I'd very much prefer:

return any([true])
match (p:player) return p.age > 35 as senior | return collect($-.senior) as seniorList  | return any($-.seniorList)

[kindlychung]

Considering we already have list comprehension, the following should be intuitively correct:

return any([n in range(1, 5) | n > 3])

At the moment this is illegal.

[jievince]

The current syntax is:

<predicate>(<variable> IN <list> WHERE <condition>)

Which can lead to bizzar statements like:

return any(n in [true] where n)
match (p:player) return p.age > 35 as senior | return collect($-.senior) as seniorList  | return any(n in $-.seniorList where n)

I'd very much prefer:

return any([true])
match (p:player) return p.age > 35 as senior | return collect($-.senior) as seniorList  | return any($-.seniorList)

Hi kindlychung,
When the list is all bool types，you think the where pattern of predicate is unnecessary. Do I get what you mean?
But the list is not strong-typed, so the list main contain other types of data,
eg. return any(n in [true, 3, "jack"]), if there is no where, what's boolean value of 3 or "jack"?

[jievince]

In list comprehension, [n in list where filter | mapping], the pattern filter is used to filter some items of the list, and the pattern mapping is used to mapping each item in the list to other value.

Considering we already have list comprehension, the following should be intuitively correct:

return any([n in range(1, 5) | n > 3])

At the moment this is illegal.
The predicate should not support mapping function, because it is contradictory with its original design intent

[kindlychung]

But the list is not strong-typed, so the list main contain other types of data

I see. Is it too late to introduce a new list type with homogeneous types at this stage?

[kindlychung]

Actually I think it can still work. Basically we can just treat any non-booleans as false. For example return any( [true, 1, 2, 3]) can just evaluate to true, while return any([2, 1, 3]) and return any([1, false, 99]) can both evaluate to false.

[jievince]

Basically we can just treat any non-booleans as false.
This is an unreasonable assumption. BTW, a predicate without specifying a filter is equivalent to this form `any(n in [true, 1,2] where toBoolean(n) == true). So toBoolean(1) returns true, toBoolean(0) returns false, and many data types like list, vertex can't be converted to a bool value.

[jievince]

But the list is not strong-typed, so the list main contain other types of data

I see. Is it too late to introduce a new list type with homogeneous types at this stage?

Writing a type of list<int> in SQL is too ugly

[kindlychung]

This is an unreasonable assumption. BTW, a predicate without specifying a filter is equivalent to this form `any(n in [true, 1,2] where toBoolean(n) == true). So toBoolean(1) returns true, toBoolean(0) returns false, and many data types like list, vertex can't be converted to a bool value.

Could you please give an example of "a predicate without a filter"? I tried this:

(root@nebula) [(none)]> return any(n in [1])
[ERROR (-7)]: SyntaxError: syntax error near `)'

An implicit where toBoolean(x) filter is nice. And if any(n in [1] where toBoolean(x) == true) can be simplified to any(n in [1] ), why not just any([1])?

[kindlychung]

Hm, it seems converting a number to boolean is not allowed in 2.0:

(root@nebula) [nba]> with 1 as x return toBoolean(1)
[ERROR (-12)]: SemanticError: `toBoolean(1)' is not a valid expression : Parameter's type error

[CPWstatic]

Thanks for introducing some convenience syntax for us, but we are now trying to be compatible with the openCypher firstly. Your proposed syntax about the any predicate seems only a syntax sugar but nothing new. And the toBoolean part is also compatible concerned that the toBoolean function supports only string to bool.