 |
lua-l archive |
|
|
||
|
On 25 July 2016 at 15:07, Coda Highland <chighland@gmail.com> wrote:
> On Mon, Jul 25, 2016 at 10:24 AM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>> Check your words. "unspecified behavior" (what the C standard says) is
>> different from "undefined behavior" (what you asked about). Lhf is
>> correct in saying that the behavior is not undefined, even though it is
>> unspecified.
>>
>> About the manual itself: there are infinite things that Lua does not do
>> but the manual fails to mention. So, if the manual does not define in
>> what order __newindex metamethods in multiple assignments are called,
>> it is safe to assume that the order is unspecified, even if the manual
>> does not say that.
>
> Respectfully, I disagree with this argument. While it is true that
> unspecified behavior is not the same as undefined behavior, undefined
> behavior is tautologically defined as "behavior that is not defined".
> The documentation for the language is the source of all definitions.
> Any behavior that is not documented is therefore, by definition,
> undefined behavior.
>
> It can be concluded syllogistically that the execution order of
> multiple assignments in Lua is undefined.
>
> All undefined behaviors are unspecified, because in the case of Lua
> the core language documentation is also the language specification.
> The distinction is that when something is defined to be unspecified,
> the scope of permissible behaviors is in the process implicitly
> defined. (In this example, defining the order of assignments as being
> unspecified would mean that any ordering would be permissible, but
> that terminating the process -- not being an ordering of the
> assignments -- would not be expected.)
>
> That said, I don't disagree with your conclusion: The manual doesn't
> say anything about it, so the order is undefined, and that's a
> completely acceptable state of being.
I might be wrong here, but I suppose some of the confusion comes from the specific jargon for "undefined" vs. "unspecified" in the C standard, where "undefined behavior" means "if you do this anything can happen in the program including blowing up your computer", while "unspecified" is used in contexts such as "saying that A and B happen in an unspecified order means that A and B will happen, but you can't know in advance what the order is when writing a portable program".
-- Hisham