implement equality for ComposedFunction structurally

[jw3126]

fix #53853

[nsajko]

Suggested change

	end
	@test ((missing ∘ sin) == (missing ∘ sin)) === missing
	@test ((missing ∘ sin) == (missing ∘ cos)) === false
	end

Not sure, but presumably we'd like to intepret ComposedFunction like a collection of functions, thus suppport missing as usual.

[jw3126]

It is a good point, but orthogonal to this PR.

[jw3126]

To clarify, right now missing is not handled specially by composion.

julia> missing∘missing
missing ∘ missing

[nsajko]

orthogonal to this PR.

I don't think so. Right now we have the excuse that == for ComposedFunction isn't implemented at all, but if we're finally implementing it presumably the handling of missing should be thought through.

right now missing is not handled specially by composion.

Composition doesn't need to handle missing specially, just ==. If ComposedFunction is interpreted as a sort of collection of functions.

[jw3126]

You are right, sorry I misread some parenthesis in your test. I read (missing ∘ sin) === missing.

[jw3126]

My takeaway from #54881 is ot not implement special logic for missing in composed function equality in this PR.

[LilithHafner]

I think it's possible to support missing without any special missing-specific logic.

[mikmoore]

I don't think it should be blocking here, and checking == for ComposedFunction seems weird and uncommon anyway, but do note that even the proposed definitions will say

julia> (sin ∘ sin) ∘ sin != sin ∘ (sin ∘ sin)
true

I.e, the binary nature of ComposedFunction's representation, contrasted with its strict right-to-left evaluation, means it is possible to construct semantically-equivalent ComposedFunction that differ only in their representation.

ComposedFunction constructed with the n-ary operator (i.e., ∘(sin, sin, sin)) will at least have consistent structure, but incremental constructions or cases where we force different associativity can have this discrepancy.

---

I do not think missing should be specially supported because it isn't callable. Any ComposedFunction call containing it will be a MethodError. If one constructs such a composition, it was almost-certainly by mistake.

[nsajko]

possible to construct semantically-equivalent ComposedFunction that differ only in their representation

Interesting. Basically, ∘ is associative and we would ideally account for this symmetry in ==, because two ComposedFunction objects that differ only by associativity will always have the same result for the same inputs. Right?

One solution would be to recursively convert the ComposedFunction to Tuple, and then compare the two tuples of functions using ==(::Tuple, ::Tuple).

[mikmoore]

Yes, you stated the issue much more clearly than I did. Possibilities would be to convert it to Tuple, canonicalize it, or to not convert them at all but simply traverse each in evaluation-order and compare their "elements" that way.

Although I think this PR would be fine even if it didn't recognize re-associated ComposedFunction as equivalent. That can be left for later. Personally, I don't remember the last time I checked == on a function (or even on a callable), much less a ComposedFunction. The likelihood that somebody assembles multiple versions with different associativity and then attempts to == them seems vanishing.

[LilithHafner]

Suggested change

	==(f1.inner, f2.inner) && ==(f1.outer, f2.outer)
	==(f1.inner, f2.inner) & ==(f1.outer, f2.outer)

Support missing and other non-Bool results of == by not short-circuiting.

[LilithHafner]

I think it's possible to support missing without any special missing-specific logic.