# SPLIT of a block not equal to the list?

I think the images explain it:

This is just a complicated wrapper around the fact that = doesn't work for blocks.

I just tested this out and this works

also this

but this doesn't

as well as this

in conclusion, it doesn't work when there's an empty value.

edit: strangely this works though

I now think it might be because the empty value from the split by block is not the same value as the empty value in a list.

That's right, you need to compare expressions by decomposing them first (on both sides of the equation):

But ITEM 4 OF on both of them gives equal results.

ok, so I did find out that the empty value created by the split by block is actually null, not ''. Here's the proof

and here's what I did to get these values

On my ever-growing wish list, but unlikely ever to happen, is for all empty lists to be EQ. But I don't know about empty text strings. Logo actually takes pains to ensure that equal words are always EQ. (That is, it interns them: adds them to a hash table of words.) It does this because words do double duty; besides being printable and subsettable and so on, they serve as symbols, to name things.

But what you're seeing is probably just a bug. It's the null that's wrong, right? (Sorry for that difficult sentence.)

JavaScript isn't Snap! Inspecting a Snap!-List in JS is meaningless and not some kind of deeper truth. There's no such thing as "null" in Snap! What you're seeing is a feature: We need to be able to distinguish expressions from functions, and I've shown you how to do that a few posts above.

Hmm. True, this seems to work:

But, Jens, this works as they're expecting:

It's only when one of the inputs is an empty string that it doesn't:

If this were about distinguishing expressions from functions, why is it only in the case of an empty text string input that the comparison gives False? I would have thought it'd be False in the case without the empty input too.

And you shouldn't be jumping all over @ego-lay_atman-bay. They're not saying that it's an error because there's a difference in the JS Console. It's an error because the behavior is unexpected only in the case of an empty input. The point of the JS is that they're trying to help you debug it!

If you don't fix this, someone is gonna complain about it again in the future. It's just bound to happen. Also, if null doesn't exist in snap, why does it not equal an empty string?

if you want to use Snap! at the end of an exclamation, please put Snap!! instead of just Snap! as to avoid run on sentences with randomly scattered capitalized improper nouns

shouldnt have to say this but...

just kidding :​P

I'm pretty sure he knows Snap<i>!</i>, but doesn't have the time.

if null doesn't exist in snap, why does it not equal an empty string?

you mean like this?

Yeah,

thats exactly what it does..

Well, snap shows null as an epty string, but...

because in JavaScript, null is not a string. if you type in [ return null == '' ] it will be false. null returns as null and '' returns as ''. in snap, null is just represented as just an empty string. it is still null, but reporting null would be confused with "null" since snap doesn't distinguish strings with quotes.

You guys aren't helping by talking about JS. That just helps convince Jens that this is a non-problem. See my comment #9 above.