parser handling of "is not null" seems buggy compared to "!= null"

[sapientN3T]

Observe the following:

c != null where c=[1,2]           // true
c is not null where c=[1,2]       // true
c is not null and c.x=1 where c=[1,2]       // type error, does not parse
((c is not null) and (c.x=1)) where c=[1,2] // still does not parse
c != null and c.x=1 where c=[1,2] // true

I also had this problem with comma-separated list comprehension conditionals, i.e.

[ ... | c<- items, c is not null, c.x=1 ] // error c is null
[ ... | c<- items, c is not null and c.x=1 ] // error c is null
[ ... | c<- items, c != null and c.x=1 ] // works fine

[ghost]

Duplicate of #6 I think..?

[sapientN3T]

@galegosimpatico maybe... I think it's different. In that case, it says c "might be" null. in this case, the parse error is different. It doesn't say that c "might be" null. It says that c is a string or that c is null, depending on the expression.

However, I just discovered that it works if I explicitly cast to Loc:

((c is not null) and ((Loc<- c).x=1)) where c=[1,2] // true

[ghost]

However, I just discovered that it works if I explicitly cast to Loc:

The left arrow style cast (<-) is covered by the documentation:

Manual Type Inference

Manual Type Inference (or type-insistence if you'd like) can be done via: string <- my_val. You'd only use this if (for whatever reason) the automatic type-inference system just can't figure something out. This is sad to use because it defeats type checking, and makes it possible to have an error at runtime, rather than load time. You might use it like so, if for some reason the engine can't see the obvious if() clause eliminating a possibility:

if(my_val is string, do_stuff(string <- myval) )

So it's a shame it's not perfect, but it works the vast majority of the time, and is overwhelmingly worth having. Having "used it in anger", the automatic type inference system is really quite good, but occasionally crazy linkages between the levels and the objects on them leave it confused as to what type something is supposed to be - even though, to a human, the obvious fact is staring the engine in the face. Typically if you run into this, a sign that this is afoot is that an object should be a specific type, but the engine is interpreting it as "of type any". It also might crop up with type unions, or special rules like the module.cfg file declaring the player objects to always be a special type.

Source at https://github.com/frogatto/frogatto/wiki/Data-Types#manual-type-inference.

You have read this already, at least once, but for the casual reader who might have not.