Seems like I'm often tripping up on optional arguments...
local fun, err = (the_code_chunk_as_string, 'b', _ENV)
-->bad argument #3 to 'load' (string expected, got table)
local fun, err = (the_code_chunk_as_string, nil, 'b', _ENV)
-->function, nil
Due to my last mistake, I was able to figure this one out. However, it's still weird a bit weird and only after thinking about it (a lot), do I see why: _ENV might be a string, so allowing the (arguably) cleaner version is ambiguous. If _ENV is a table, then it cannot be used, so you could infer the correct meaning, but only in cases where _ENV wasn't a string....
So, if I do have a suggestion, explicitly calling attention to this detail may make the reference guide clearer. I was not able to pick up on this, except in retrospect and then only by noticing what was not written ("in case _ENV is nil and mode is a non-string value, then..").
I'm not sure how to say this with the proper amount of respect, but speaking directly from my perspective: `load`'s interface seems messy to me. I wish that it was done in a way that didn't cause these kind of mental backflips, even though I see that putting the load function before the code that it modifies is logical.
load(code_str, fun, mode, env)
or....
demand nil for all missing arguments that are proceeded by other non-nil values....
...would work better, as far as I can tell. (and break a bunch of existing code and is probably not worth it.... so I'm just complaining.)
-Andrew
