Control flow in algorithms about infra

[domenic]

Yeah, I think "continue" is pretty much a loop thing in every language I'm aware of; using it outside loop contexts seems pretty confusing to me.

[annevk]

If we could use "continue" in arbitrary nested steps, that would address the "abort these substeps" case (means hand to the parent). And use "return" for the other scenario.

[tobie]

The problem with using "return" in that context is for when you have async stuff going and want to write something like:

1.  Do sync stuff.
1.  Return and run the following sub-steps [=in parallel=]:
    1.  Do async stuff.
    1.  More async stuff.

[domenic]

This is a tricky area and I'm not sure there are any great answers :-/. A few thoughts that have run through my mind:

---

My main problem with @annevk's preferred "abort these subⁿsteps" is that you never know if a spec is using it or not. So if you see:

1. Do X
1. If y, then:
   1. Do y1
   2. If z, then:
      1. Do z1
      2. If q, abort these steps.
1. Do R

Then "abort these steps" is ambiguous:

• It could be authored by someone like @annevk who uses the "abort these subⁿsteps" convention. In that case, "steps" refers to the entire algorithm, so the entire algorithm gets aborted, and "Do R" does not happen.
• It could be authored by someone else who doesn't use that convention. (For example, most of HTML, I believe.) In that case "steps" probably only refers to the current set of subsubsteps, so only the current set of subsubsteps gets aborted, and "Do R" happens.

Another issue with "abort these subⁿsteps" is that I don't believe it has any counterpart in most programming languages. (Besides maybe factoring things out into a smaller function and using return).

---

I have never liked the "Return and run the following sub-steps [=in parallel=]" construct, despite its prevalence across many specs. Precisely because in most programming languages it's impossible to do something after returning. Maybe we could ban that in Infra-using specs? Meh, that would invalidate much of HTML, which uses it a lot.

---

In general the things that are unambiguous are:

• "Abort this algorithm"
• "Jump to the step labeled x".

Maybe we should strive to only use those things? (Plus return and throw.)

[annevk]

@domenic you didn't mention "continue". I guess you don't want to use that outside contexts where JavaScript uses it?

[jyasskin]

Maybe labeled substeps, a'la Java:

1. Do X
2. Foo: If y, then:
   1. Do y1
   2. If z, then:
      1. Do z1
      2. If q, abort the Foo substeps.
3. Do R

[annevk]

More thoughts and some questions:

I'm not a big fan of subNsteps either. The question is how would we rewrite those algorithms today? (I looked through DOM and it doesn't really need that convention at all, so it would be trivial to get rid of there at least. Just need to do it and someone to review it.)

I tend to agree that return and run is rather sad and run in parallel and then return would work better. (Soft-)banning that in Infra seems acceptable, since much of HTML doesn't conform to all the rules we write down here.

Using return from in parallel steps seems fine to me as well, it'll just terminate those steps and that's it. (But then again, I don't quite like in parallel to begin with and I think we can do better.)

I think we should strongly consider labeled steps. URL has them, DOM has them, I think HTML has them in a few places. They're a little ugly, especially "jump to", but also fairly readable. Thoughts?

[domenic]

Using return from in parallel steps seems fine to me as well, it'll just terminate those steps and that's it. (But then again, I don't quite like in parallel to begin with and I think we can do better.)

I think that'd be confusing if used within the context of a larger algorithm; are you returning from the algorithm or from the in-parallel substeps? @jyasskin's #56 (comment) idea might be the best we have there.

I think we should strongly consider labeled steps. URL has them, DOM has them, I think HTML has them in a few places. They're a little ugly, especially "jump to", but also fairly readable. Thoughts?

In general I like them. I guess the trick is to not overuse them when break or continue would do.

There is the whole "goto considered harmful" business though, and I wonder if we have any good arguments for why that might apply less to specs.

It'd be good to make these decisions with some more cases in mind. E.g. pick 3-6 algorithms from various specs and analyze how we'd ideally write them.

[annevk]

@domenic and I discussed labels a bit more on IRC. Given http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html and the ability for standards to refactor we're somewhat less inclined to add it. Figuring out how to rewrite existing usage is still important of course.

We also thought that perhaps standards use functions less is because other standards might use them as hooks, so being able to distinguish between public and private API more clearly was seen as something nice potentially. (And in terms of the Bikeshed dfn protocol, there's some need to export private functions sometimes. For monkey patching and explaining the interweaving of standards (e.g., CSP and Fetch).)

[jyasskin]

2 things:

1. Breaking from a labeled level of a control structure is different from arbitrary gotos. I mentioned Java on purpose, since it omitted arbitrary gotos.
2. Refactoring a function that's only used once out of an algorithm can make that algorithm harder to understand. Not always, of course, but I think we should let editors and spec reviewers use their judgement instead of saying that you can only express certain things by factoring out a helper function.

[tabatkins]

Another issue with "abort these subnsteps" is that I don't believe it has any counterpart in most programming languages.

Nit: a number of languages have labeled or numbered break statements, that can break out of multiple nested constructs at once.

[annevk]

Concluding this thread:

• Labeled steps is now #119.
• In parallel is #120.
• We'll continue to remove "substeps" from existing algorithms. Feel free to file bugs when you come across instances. (I already cleaned up a bit in DOM/URL/HTML.)