Open nsajko opened 3 months ago
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.
For better or worse, the ternary logic including missing
is part of the semantics of ==
.
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.
But it seems like we should actually have
==
returnmissing
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.
If
==((;f1,g1)::ComposedFunction, (;f2,g2)::ComposedFunction) = f1 == f2 && f2 == g2
, then this should returnmissing
. 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:
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. :slightly_smiling_face:
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.
The current behavior is:
But it seems like we should actually have
==
returnmissing
in this case? This is becausemissing
basically represents a wildcard function here, the way I interpret it at least. This would be analogous to, e.g.:This is a special case to consider for #53853.
Not sure if I should label this for triage, but it'd be nice to get a quick decision here, given that it's relevant to @jw3126's PR #54877.