Should `==` over `ComposedFunction` support `missing` as usual about julia HOT 6 OPEN

please, no

I think Missing should stay in its statistics corner and only propagate in statistical contexts

Imo it already propagates through far too many functions.

from julia.

For better or worse, the ternary logic including missing is part of the semantics of ==.

from julia.

wait, why does missing work with ∘ in the first place? it's not a function

I'd sooner special case an error path for ∘(::Missing) than make it propagate.

from julia.

But it seems like we should actually have == return missing in this case?

If ==((;f1,g1)::ComposedFunction, (;f2,g2)::ComposedFunction) = f1 == f2 && f2 == g2, then this should return missing. I don't think there's another result that makes sense.

why does missing work with ∘ in the first place? it's not a function

∘ takes any value, it doesn't know if they're callable until it tries to call them. That's basically the julia style. If it's necessary to know statically that there's a problem then JET will detect the problem at the problem where the invalid call occurs, not where the construction occurs. Just like you can make a list of [abs, exp, missing] and it doesn't error until you try to call them.

from julia.

If ==((;f1,g1)::ComposedFunction, (;f2,g2)::ComposedFunction) = f1 == f2 && f2 == g2, then this should return missing. I don't think there's another result that makes sense.

I don't think so, && will error on missing first argument:

julia> missing && true
ERROR: TypeError: non-boolean (Missing) used in boolean context
Stacktrace:

from julia.

Ah yeah, true && missing returns missing and missing && true errors. So if the implementation is structural, the result might depend on the order in which the components are checked. ComposedFunction components have an obvious "order" to them (namely, application order), so it seems fine to implement == structurally using the application order.

I don't like the idea of introducing a special case error specifically to make sure missing doesn't propagate: Missing is the type designed for propagating missingness, after all. 🙂

If a user wants to create a collection of callables, some of which some are missing, and then ∘ them together, I think they should be able to do that, and expect the behavior to compose too, following the specifications of the components (==, ComposedFunction, and Missing), without needing to also consider a special rule that only takes effect when these three things are combined.

from julia.