Re: 5.4 Incompatibilities with the Previous Version

[Viacheslav Usov <via.usov@...>]

On Tue, Sep 21, 2021 at 8:30 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:

> That is why I asked for real code. Lua is a dynamic language. If
> we consider toy examples, any single change to the language breaks
> something.

The problem with "breaks somethings", as well as with the word
"incompatible" that is used in the manual, is that it is subject to
interpretation.

For example, the change in behavior of math.random() is listed as
incompatible. However, the behavior in 5.3 is documented as "an
interface to the underlying pseudo-random generator function provided
by C". Which, to a Lua non-C user, means exactly nothing. And even
then it is not true, because Lua 5.3 in fact tries to use Posix
random() when it can. And when it cannot, the C-standard rand() has no
such guarantee as "uniform distribution" claimed by the manual [1].
Even when uniform distribution is available, it is observable only if
every seeding and generation operation is done deterministically,
which, in principle, is not something that hosted Lua code could
guarantee. Practically, math.random() may behave not as documented,
thus it is "broken". This is, of course, why it changed in 5.4. On the
other hand, we could say that it is the behavior, not the manual, that
is correct, in which case the change from the less constrained
behavior in 5.3 to a more constrained behavior [2] can hardly be
regarded as "incompatible".

Therefore, if the section in the manual replaced the word
"incompatibilities" with something like "notable changes", there would
not be a need for somebody to separate "real" from "toy" usage and
argue about their elusive distinctions. Another alternative would be
to list every change, in which case the change in require() should
appear there.

Cheers,
V.

[1] As of C11, the standard warns that the quality of rand() is not
guaranteed and can be "distressingly non-random".

[2] Even in 5.4, a Lua script might practically be unable to observe
the available determinism and uniform distribution. If a script calls
some other Lua code (library), the other code can call math.random()
and math.randomseed(), which will interfere with the "main" Lua code,
because all the Lua code in a Lua state (VM) uses the same PRNG state.
In a sufficiently large project, this should be considered a given.
This could be remedied by exposing a private PRNG state as an object,
for example:

local gen = math.randomgenerator()

The existing PRNG functions could be extended (or new functions added)
that would use the private state (gen) rather than the default PRNG
state.