Re: load functions arguments

[Jerome Vuarand <jerome.vuarand@...>]

2014-11-05 17:09 GMT+00:00 Andrew Starks <andrew.starks@trms.com>:
> 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..").

The error message seems pretty explicit to me. It tells you exactly
where to look at, in your case you pass _ENV as third argument while
the manual expects a "mode".

> 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,

What backflips are you talking about? When a function expects an
argument and the caller doesn't provide it, its value is nil. This is
true for any Lua function. That sounds very consistent to me, I don't
see how you can single out "load" as being messy.

> even though I see that putting the load function before the code that it
> modifies is logical.

What code is modified?

> load(code_str, fun, mode, env)

What's "fun" here? The second argument to load (in 5.2) is just a
debug string that will be used when a runtime error happens in the
compiled code.

> 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.)

How would that be better? The default behaviour of Lua when a function
has a named argument and the called doesn't provide it is to set it to
nil. The default behaviour of Lua when a caller pass extra arguments
to a (non-vararg) function is to ignore them. While it's possible to
circumvent that default (at the expense of not naming arguments), this
sounds to me like breaking expectations, unless you're advocating a
whole paradigm shift in the Language.