`IN` operator does not work with literals

[jeswr]

`IN` operator does not work with literals

[rubensworks]

@jitsedesmet Could you look into this one? Probably related to #1146.

[rubensworks]

In conclusion, yes we can apply this change.

Makes sense to me!

Just had a look at the spec as well, and it does indeed not say anything about if AFAICS, but we can indeed add support via operator extensibility.

So feel free to go ahead with making a PR @jitsedesmet! :-)

So concretely, we should make it so that the warning is not shown anymore. But plain strings and language-tagged strings will remain non-equal.

[github-actions]

Thanks for reporting!

[jitsedesmet]

This is definitely a sparqlee issue. The in operator is a spacial operator in sparlee and for some reason it states:

This function doesn't require type promotion or subtype-substitution, everything works on TermExpression

I don't seem to remember why this is the case, so I'll need to look into that.
It might have to do with the fact that equality requires the types to be equal anyway? I'll look into this deeper next week.

[jitsedesmet]

My commend above was false. This behavior is what we/ I expected.
When resolving the issue, we had a conversation about comparing 2 strings that are not equal and whether this should raise an error. We concluded this discussion with "we will add support for language strings". This is true, we added support for language strings, so comparing 2 non-equal language strings would not throw an error. Nothing was said about comparing a language string with a normal string... And thus, an error is still thrown in this case.

We could easily allow comparing a string and a language string (it would even make the code easier), question is; do we want this?

[rubensworks]

Ok, a language-tagged string not being equal to a non-language-tagged string definitely makes sense.

I'm just wondering if the warning messages are correct here.
@jitsedesmet does the spec say that an error must be thrown when comparing a language-tagged string with a language-tagged string? If it doesn't say that, perhaps we can just make it return false without throwing the error?

[jitsedesmet]

The warning is correct since we don't implement an equality between a string and a language string, i.e. we don't find a fitting function.
I think it would make sense to just return false in this case instead of an error. (which we can do for the same reason as with the implementation of language string equality.)

Should I make a PR for this in sparqlee?

[rubensworks]

The warning is correct since we don't implement an equality between a string and a language string, i.e. we don't find a fitting function.
I think it would make sense to just return false in this case instead of an error. (which we can do for the same reason as with the implementation of language string equality.)

But what does the spec say?
Does the spec say that we should throw an error?
Or is this undefined behaviour in the spec?

[jitsedesmet]

I'm pretty sure the spec doesn't care. In your comment here: comunica/sparqlee#168 (comment) You mentioned the use of operator extensability. This can be used here too.

The operator in states:

The test is done with "=" operator, which tests for the same value, as determined by the operator mapping.

In conclusion, yes we can apply this change.

Please tell me if I misunderstood your question.

[jitsedesmet]

Yes, will do!