Deprecated squeeze with emulation path is missing its own section

[anssiko]

Since the previous CR we removed squeeze (in PR #532) that can be generically emulated and expressed in terms of other low-level operations. Now the informative squeeze emulation note is plugged into the lstm section which is wrong. We should keep this note in its own squeeze section.

Considering deprecations may be expected in the future too, we should agree on how to best structure the spec for this:

• keep deprecated ops in the top-level API section: remove all the normative content and leave only the informative emulation note in place, maybe annotate the title with "deprecated"
• add a new top-level section for deprecated ops next to the API top-level

Thoughts? Is the first option better?

[inexorabletash]

Now the informative squeeze emulation note is plugged into the lstm section which is wrong. We should keep this note in its own squeeze section.

Is that correct? I see gru and lstm both include a very abbreviated function squeeze definition in their "generically emulated" section, but it's in reshape itself that gives a more comprehensive example for how reshape can be used to emulate squeeze.

Regarding structure, perhaps a non-normative section in the appendix giving emulations/decompositions of popular ops that don't make the cut?

(Actually removing ops from the TR/final version of the spec seems unlikely given how hard deprecations on the web are... we've been working on deprecating WebSQL for over a decade.)

[huningxin]

Regarding structure, perhaps a non-normative section in the appendix giving emulations/decompositions of popular ops that don't make the cut?

+1

[anssiko]

A refined proposal: move all those "The behavior of this operation can be generically emulated" boxes to an appendix section. All of them, not just those that didn't make it to the API proper. Currently there's 20 of these boxes. (And check they're valid, preferably with tests.)

It is OK to have alternative emulations for a single op, each with their own tradeoffs.

I feel it might improve readability and make it easier for editors to evolve the spec if we section these out.

Thoughts?

[inexorabletash]

FWIW, I prefer having the emulations/decompositions for ops supported in the API right in the definitions. It helps me mentally partition the ops into "low level" and "high level" (which I've also heard referred to as "core" and "composite", or "RISC" and "CISC"), and goes slightly towards addressing #462

But that could also be done by organizing the ops differently (different order or different sections?) or just calling out the ops that can be decomposed by some standard text in their introduction.

[anssiko]

Re calling out, a good idea. I envision a standard note banner for those decomposable linking to the appendix where the emulation code sits:

”The behavior of this operation can be generically emulated, see link-to-appendix.”

I think our intent has been to try include emulation code for all decomposable.

We have sectioned out element-wise, pooling, reduction ops due to their similarity while the rest are in the ”global namespace”. More structure could be added with those ”this is decomposable” banners. Would that help you @inexorabletash?

I’d let the editors choose an approach that feels the most productive way forward for them. Maybe in small steps first, check the current emulation code is in its logical place before making huge changes.

[inexorabletash]

More structure could be added with those ”this is decomposable” banners.

SGTM, but defer to the editors.