Clarify termination scope

[chaals]

https://infra.spec.whatwg.org/commit-snapshots/3e751ef04a007e73b10c2be3a5e980e3a7858804/#algorithm-control-flow

The control flow of algorithms is such that a requirement to "return" or "throw" terminates the algorithm the statement was in. "Return" will hand the given value, if any, to its caller. "Throw" will make the caller automatically rethrow the given value, if any, and thereby terminate the caller’s algorithm. Using prose the caller has the ability to "catch" the exception and perform another action.

3.7. Conditional abort
Sometimes it is useful to stop performing a series of steps once a condition becomes true.

I think it would be helpful to be clearer about the scope of things that terminate some steps. The problem I saw was an algorithm that had several sets of substeps, e.g.

...
4. Then do this
  1. something interesting
  2. something else
  3. if some condition, abort these steps.
...

It appeared to me that the meaning of substep 3 was to terminate the algorithm. When I read the conditional abort section, it seems to imply that "abort when" is intended to terminate a set of substeps.

I also found the section on returns and throws unclear about scoping. I'm not sure if the best thing is to add some phrasing to existing content, define scoping of termination specifically, or something else.

[chaals]

(It might just be me and it's definitely in the realm of "bikeshedding", but I generally prefer the word "terminate" as it feels slightly less charged in contemporary usage).

[marcoscaceres]

Personally, I don't think this is an infra issue (Infra is more of a "standard library" for specs, providing handy primitives like lists, maps. etc.).

It's more of a "how to write a spec" issue. We should eventually write a guide on best practices for spec writing.

[chaals]

As long as infra describes things to use in algorithms, I think this belongs there. After all, people are copying the style and usage across multiple specifications, and the point of infra is to help them do that appropriately. Relying on algorithms as a definitive normative explanation, when they are expressed in an undocumented format that allows for ambiguities, can have the effect of "hiding" those ambiguities behind an appearance of rigour.

(I appreciate having algorithms, but I hope a best practices guide will include "explain what happens in prose even if it's non-normative, instead of assuming that the algorithms are self-explanatory". )

[annevk]

I agree that it would be good to clarify this.

Algorithms are either introduced as an algorithm or as "these steps". Algorithms sometimes end up being nested, e.g., if you want to run something "in parallel" to the current algorithm you end up creating a nested algorithm. This also applies to callback-like algorithms that are somewhat common with fetch.

Return and throw are scoped to a single algorithm. "Abort these steps" is also scoped to a single algorithm, but not currently defined. It is typically in use with "in parallel" algorithms because those cannot really return anything. They have to queue a task (perform IPC) to get data back to the other thread.

"Abort when" is a very specific construct with no relation to "abort these steps".

So thoughts based on that:

• HTML defines "in parallel". It probably ought to define "abort these steps" and maybe we should try to exclusively use it for these top-level "in parallel" algorithms? (If we want to use it more broadly Infra should probably define it as a synonym for return without argument.)
• Infra could maybe do a better job at defining an algorithm. E.g., defining "block scope" itself rather than referring to Wikipedia. This might be rather tricky to do though.