NoSuchAtributeNamesError when `where true = true`

[YuMingLiao]

TutorialD (master/main): :showexpr true where true = true
ERR: NoSuchAttributeNamesError (fromList ["true"])
TutorialD (master/main): :showexpr true where true /= true
┌┐
││
└┘
TutorialD (master/main): :showexpr true where relation{tuple{}} = true
┌┐
││
├┤
└┘
TutorialD (master/main): :showexpr true where true = relation{tuple{}}
ERR: NoSuchAttributeNamesError (fromList ["true"])
TutorialD (master/main): 

[YuMingLiao]

Oops, I just wrongly thought left side of equal could be anything.

[agentm]

Actually, I think that this is worth discussing. The current implementation assumes that the each left side of the equality is an attribute, but I think it's fair to request that:

x where @y=3;
x where 3=@y;

should be the same query. The problem in the current code is due to the desire to keep the grammar context free. In the query:

x where y=z

x is unambiguously an relvar but y and z could be relvars. If y is a relvar and z is an attribute, then z must be a relation-valued attribute. In order to keep the grammar context-free so that the backend doesn't have to guess (sometimes incorrectly) whether the attribute or the relvar is intended, we have adopted the @attribute syntax where needed to disambiguate. This could be done here as well:

x where @y=@z

unambiguously refers to y and z as attributes. (This syntax is not currently supported.) However, this means that referring to attributes in the where filter will always require the "@" sign. It seems like a sweeping change, but perhaps it is worth it to keep the syntax unambiguous. What do you think? Would you mind using the at-sign wherever an attribute is used? Is there a better alternative?

[YuMingLiao]

Good question... do we really need an relvar on the left side? (I was trying that if x where true = true leaves x untouched.) I can't think of a useful case.

Right now, we don't need to use @ on the left side of =, and when I use where operator, I feel like I am querying something. So "only attribute name on the left side" seems right. And I don't mind use @ in right side of = in where and := in extend. It reminds me it is a calculation by row/tuple. Now, I don't feel right if it is omitted on the right side of = and :=.

So the design right now feels right to me.

But If we want to omit @ at all ... How about this? Where and extend always brings variable names (attribute names) into scope. We make a rule that attribute name is always over relvar name (if you want to use some relvar, just use alias to rename it.) then names will always refer to the nearest value in nested where and extend.

I sometimes want to use @attr where ... but failed. But I have managed to find a way to bypass the need.

My conclusion for now is there is no need to change.