The meaning of "considered equal" should be specified more clearly somewhere

[IreneKnapp]

The semantics texts for all the equalto* builtins simply say "are considered equal to each other", and don't elaborate on the meaning of that. There are many notions of equality in computing! Certainly the builtin docs would be a bad place to put this explanation, since it would be far from discoverable; ideally there should be a section of the semantics chapter talking about it, and the docs for each relevant builtin should ideally link to that.

What that would actually say is something to the effect of "Modern Data only takes a position on equality for values belonging to its own primitive types, and only the atomic ones, ie not sigma or lambda, and certainly not for types-as-values. For the purpose of comparison, each comparand is fully evaluated, which, since these types are atomic, results in a single node for each. These nodes are then compared for being of the same type and holding the same value."

Except it should flow better than that.

Also, thinking about this made me realize the issue I describe in https://github.com/IreneKnapp/modern-data/issues/5. :)

[tinyplasticgreyknight]

I guess the exact notions for the various primitive types are:

• bool: equality of enum
• ints, nats: numeric equality
• name: equality of hash values
• ordering: equality of enum
• blob: byte-by-byte comparison
• utf-8: character-by-character comparison
• floats: since denormalized floats and -0 aren't allowed, can this just be equality of the bitwise representation? (related to https://github.com/tinyplasticgreyknight/modern-docs/issues/16 since the ordering builtins also need to express the concept of float equality)

[IreneKnapp]

Yes to all of those. In the case of floats, were they allowed, -0 would have its own distinctive representation, but denormalized floats and NaNs would each have many "equal" representations that were different bitwise. Because these are not allowed, bitwise comparison works even for floats.