lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 30.03.2014 23:16 schröbte Andrew Starks:

If 5.3 has new keywords, then global is just one more parser issue to trap,
so it's not a big deal to trap this one too.

So far 5.3 doesn't have new keywords. It has new bitwise operators, but luckily most modules/programs can live without those. Undefined globals are more common (at least in my code), e.g. unpack, setfenv, loadstring, jit. (I recently looked at some OO modules, and some of them still put classes in the environment table.)

2: _STRICT is a value that is global and defaults to `false` (or nil,
but one must be able to assign it globally).

Why not just preload `strict.lua` instead?!

I can do that. My point is that a natural method would make it more
pervasive and less likely to be imemented in conflicting ways.

It would be `require( 'strict' )` vs `_STRICT = true`. The first one is already pervasive (and quite natural) for all people using `strict.lua`. And what's wrong with conflicting implementations (as long as you use only one at a time)?

Then people can `require` it if they want to. But I'd rather use something
that works offline (at compile time), or at least can be enabled/disabled
on a per-chunk basis (maybe as a fallback to the offline tool).

  I think that my suggestion achieves that with _STRICT

I might be missing something, though.

The value of a global variable is a dynamic thing, so it is not restricted to a certain chunk. You would need something like:

    local old_STRICT = _STRICT
    _STRICT = false
    local val = mod.func() -- call function in a non-strict module
    _STRICT = old_STRICT

and that would disable strict checking for all functions called via `mod.func()`, even the ones defined in a "strict module".

You could make something like `require 'strict'()` work per-chunk using the same techniques as the infamous `module` function. It would still be redundant for me because I use static checking anyway, but at least it wouldn't get in the way ...