Re: 5.2 feature list?

[Mark Hamburg <mhamburg@...>]

Local-by-default doesn't work. That issue should be dead. And if we can't
kill it, then let's introduce a forum where people can discuss it to their
hearts content.

Global-by-default has two problems.

One is that it generates less efficient code. If you could have gotten by
with a local declaration, your code might be more efficient.

The second is that it hides typos unless you wrap the code with an
environment that complains about setting globals. A compiler could have
caught those bugs if globals had to be declared and hence would catch them
sooner than a test that requires running the code.

The downside to requiring declarations for globals is that it interferes
with interactive execution. It also needs a backdoor by which one can
pre-declare at least some globals. Both of those issues can be handled, but
any proposal to require declarations for globals does need to address them.

If one were really concerned about typos, we would also require declarations
for fields and methods so that the compiler could check that names used in
those positions were correct. But then we would also be worrying about how
to validate the declarations. So, maybe the best option would be a compiler
hook to "lint" the use of various names -- e.g., a function that would
return true or false in response to calls like:

    check( "read_global", "foo" )
    check( "write_global", "foo" )
    check( "read_field", "baz" )
    check( "write_field", "baz" )
    check( "call_method", "bar" )

It is then up to the host code to decide what checks it wants to impose.

The compiler would only need to check each operation/name pair once, so this
need not slow things down excessively.

The benefit of something like this relative to lint tools based on looking
at the byte-codes is that they can generate error messages at the point of
disallowed usage rather than forcing the programmer to search through the
code looking for the global reference that should have been declared local.

Mark