Since NIL is able to import Lua scripts and use all global variables that script defines, a small issue can arise. After all Lua does not only deem any value not yet defined as 'nil', but it also deems all variables containing 'nil' as non-existent, and whatever is deemed non-existent by Lua when it comes to scripts written in Lua in stead of NIL, will also be deemed non-existent by NIL.

Some Lua modules however can have global variables containing 'nil' values when these are not in used, and although this is bad practice (as you should not really rely on globals in that kind of manner), NIL needs to be able to deal with that kind of situation. And then the '#accept' directive comes in place.

'#accept' will only tell NIL a variable exists. NIL won't assign any value whatsoever to it, NIL will just know it exists, and will therefore accept it as a variant variable.

#accept MyVariable
print(MyVariable)

Why not just declare it in NIL, you wonder... Because NIL will always define the default value to it, which is in the case of a variant 'nil'

global var print

This effectively turns print into a nil-value, and nowhere in the code can it be used again, unless you redefine it. '#accept' won't do that.

When do I need '#accept'?

If you write clean code, and those who wrote the libraries and modules you import into NIL also wrote clean code, then the answer is NEVER, and then you should ignore the fact that it exists. If this is not the case '#accept' can at least take the bad results such a thing can bring away (although you may consider a different coding style, or to import a module that works has been written in a better way. The need of '#accept' always means you're dealing with dirty code, straight from Hell or worse).