[Same neighbourhood as Bug 3918, but different.]
In B.3.3 "Block-Level Function Declarations Web Legacy Compatibility Semantics",
we're given an algorithm that modifies/replaces algorithms elsewhere in the spec (9.2.13 and 14.1.23). That alone would be odd, but what's even odder is that these changes aren't 'universal', i.e. the changes only affect *some* applications of the changed algorithms. So now we have to imagine that for each affected algorithm, there are actually two versions, with the choice of which to use for any given application being made somewhat magically.
I think a far more straightforward approach would be to take the steps 2.a.* and 2.b.* out of the B.3.3 algorithm, and insert them at the corresponding points in 9.2.13 and 14.1.23 respectively, but embed them in an 'If' that only invokes them when appropriate. The condition would be something along the lines of:
the ECMAScript host implements the annex B.3.3 extension
and
we're dealing with a FunctionDeclaration that's affected by that extension
It would probably make sense to define an abstract operation that ascertains whether a FunctionDeclaration is affected by the B.3.3 extension. It would use the remains of the B.3.3 algorithm, and also some of its preamble, something like:
1. Assert: /f/ is a /FunctionDeclaration/.
2. If /f/ is directly contained in the /StatementList/ of a /Block/,
/CaseClause/, or /DefaultClause/ that is part of the function code
of non-strict mode function /g/, then
a. Let F be StringValue of the BindingIdentifier of /f/.
b. If replacing /f/ with a /VariableStatement/ [etc], then return true.
3. Return false
I really don't want to embed annex B semantics into the main body of the specification. Instead I placed marker place holder step in 89.2.13 and a note in 14.1.21 reference B.3.3
fixed in rev34 editor's draft
(In reply to Allen Wirfs-Brock from comment #1)
> I really don't want to embed annex B semantics into the main body of the
> specification.
Yeah, I can understand that.
Okay, how about something in-between: the annex B semantics stay in annex B, but you still get rid of the weirdness of an algorithm that makes variants of other algorithms. Specifically, B.3.3 could say (something like):
Step 29 of the algorithm in 9.2.13 is replaced with the following step:
29. If $code is the FunctionBody of a FunctionDeclaration f,
and f is affected by B.3.3, then:
i. Let F be StringValue of the BindingIdentifier of f.
ii. NOTE A var binding for F ...
iii. If instantiated VarNames does not contain F, ...
The FunctionDeclaration Evaluation algorithm in 14.1.23 is replaced with:
1. If this FunctionDeclaration is affected by B.3.3, then:
a. Let F be StringValue of the BindingIdentifier of this FunctionDecl
b. Let fenv be ...
c. Let benv be ...
d. [etc]
2. Else, return NormalCompletion(empty)
where "is affected by B.3.3" could be a suitably-named abstract operation that you also define in B.3.3.
fixed in rev34