Early error vs. error on first call to function vs. runtime error

[Brendan Eich]

Oliver Hunt wrote:
> On Sep 27, 2012, at 10:54 PM, Brendan Eich<brendan at mozilla.org>  wrote:
>
>> Oliver Hunt wrote:
>>> I'm generally against error on first call -- in the general case if you're able to determine a function should fail on first execution you can determine that it could fail during parsing and semantic analysis.
>> Ok, to play fair I should ask how you feel about any analysis that is not "cheap enough" to do during a parse or lex/read pass required to lazily compile functions on first call. What about binding analysis, recognizing every statically resolvable use of a definition, possibly making free variable uses early errors when inside module {...}?
>
> I am still not sure whether modules are expected to have a containing scope,

Yes, the global object and (we agreed last week) its lexical contour for 
let/const/class/module bindings.

Note also that the design wants to allow modules to nest in top level 
blocks, so outer blocks' let/const/function bindings could be in a 
module's scope.

Then the solution (from the 1JS era early this year) for free variable 
errors would make any properties of the global object already bound when 
the modulel is parsed be bound in the module's scope. So you wouldn't 
get a free variable error for 'alert', or the many other DOM bindings 
and global scope pollutions.

>   but either way noticing free var references during parsing in not a problem (why would it be?)

Because it requires use/def analysis, let's call it "definite binding 
analysis". Just to parse JS, one need not do any such analysis.

> the reason I didn't say "all cases" is because resolution of an unbound global property obviously can't be determined during parsing, it also doesn't make sense to fail before the access (ignoring backwards compat issues entirely here the obviate this problem).

In a module {...} there wouldn't be any such backward compatibility problem.

It would make sense to fail early if the cause of the free variable not 
matching anything in the global object at the time the module is parsed 
is that you've typo'ed the name! This is quite common.

You're right it could break extant code that migrates into a module. One 
can make a global by assignment in non-strict code, and this could be 
hidden from any analysis.

There's a trade-off, but catching free variable typos seems important.

> I'm not sure what classes of error would warrant exception on initial execution vs. just failing on sema, could you give an example?

ES5 defines a number of normative early errors in Clause 16. We've just 
been discussing duplicate formal parameters in a strict function's head, 
e.g.

/be