Re: Lua and backwards compatibility - was Re: [ANN] Lua 5.3.4 (rc2) now available,

[Coda Highland <chighland@...>]

On Thu, Jan 12, 2017 at 6:44 AM, Nagaev Boris <bnagaev@gmail.com> wrote:
>> OTOH, Lua wouldn't be the language it is today if backwards compatibility
>> was a higher priority. Features like closures over mutable variables and
>> stackful coroutines wouldn't have been developed; features which arguably
>> are now defining characteristics of Lua relative to other languages. Other
>> than Scheme, I can't think of any other non-academic language with similarly
>> powerful constructs.
>
> Go seems to have variables mutable from closures.
> https://play.golang.org/p/o23Z6bbUTp

C++, Obj-C, and Javascript have them too. It's not all THAT rare.

Python and C/C++ (and maybe Obj-C?) have stackful coroutines.

/s/ Adam

On Thu, Jan 12, 2017 at 6:44 AM, Nagaev Boris <bnagaev@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 1:18 AM, William Ahern
> <william@25thandclement.com> wrote:
>> On Thu, Jan 12, 2017 at 12:02:49AM +0000, Dibyendu Majumdar wrote:
>>> On 11 January 2017 at 21:06, Hisham <h@hisham.hm> wrote:
>>> > On 11 January 2017 at 17:08, Roberto Ierusalimschy
>>> > <roberto@inf.puc-rio.br> wrote:
>>> >>> Please, do not make such a severely breaking change in a 5.3.x release.
>>> >>
>>> >> We did not realize that. It will be corrected.
>>> >
>>> > Thank you! :)
>>> >
>>>
>>> Hi,
>>>
>>> I was wondering if it is possible to consider making strong backwards
>>> compatibility guarantees for Lua from 5.3 upwards. I think this will
>>> mean some constraints to Lua's development obviously, but it would
>>> strengthen Lua 's ecosystem.
>>>
>>> The strongest argument I could make is that Lua is built on C, and
>>> imagine how difficult it would have been if C had kept changing in
>>> incompatible ways every few years, and all new C compilers stopped
>>> supporting older versions of C.
>>
>> OTOH, Lua wouldn't be the language it is today if backwards compatibility
>> was a higher priority. Features like closures over mutable variables and
>> stackful coroutines wouldn't have been developed; features which arguably
>> are now defining characteristics of Lua relative to other languages. Other
>> than Scheme, I can't think of any other non-academic language with similarly
>> powerful constructs.
>
> Go seems to have variables mutable from closures.
> https://play.golang.org/p/o23Z6bbUTp
>
>> And that's largely because before they get there
>> language designers and implementers decide their language is "good enough"
>> and switch into long-term maintenance mode where, at best, only pale
>> imitations of the above can be added.
>>
>> If Lua were more like Python, where backwards compatibility was sacrificed
>> for much less expressive, only marginally better constructs, the argument
>> for more stable changes would be stronger. But are you really prepared to
>> say that Lua 5.3 is "good enough"? Why wasn't Lua 5.1 good enough? It's an
>> important question because LuaJIT is fully committed to the semantics of Lua
>> 5.1, and the LuaJIT community is probably larger than that of Lua 5.3.
>>
>> If Lua 5.3 really is good enough, given Lua's track record I would expect
>> future versions to naturally maintain strong backwards compatibility,
>> regardless of any specific intent to do so. Indeed, for most problems it's
>> trivial to write Lua 5.1, 5.2, and 5.3 compatible code.
>>
>> But if it turns out that Lua 5.3 isn't good enough--that there are more
>> powerful constructs or semantics that would work well in the Lua-language
>> family--it would be a shame to forgo that experiment.
>>
>> Preserving the ability and motivation for substantial experimentation means
>> we sometimes get incompatibilities, like with __ipairs[1], that have
>> arguably poor cost+benefit tradeoffs. But there's no way to avoid those
>> while also preserving the ability to adopt really greats changes. The true
>> cost+benefit can only be known in hindsight, and so failure has to remain an
>> option.
>>
>>
>> [1] My beef is that __len forecloses lazy evaluation. I'd personally have
>> liked to see __ipairs preserved with a fallback to __len. But I can totally
>> understand how that might seem too awkward. And I can appreciate the desire
>> to circumscibe the complexity of metamethods. __pairs and especially
>> __ipairs were already concessions in the sense that, unlike __call or __gc,
>> they're trivial to implement in user code and don't directly supplement the
>> language semantics. __len makes alot more sense as a language addition, and
>> I'd have been blissfully ignorant had __len come first. I guess the
>> evolution of __pairs begetting __ipairs begetting __len is a great example
>> of how even at a micro-scale Lua iteratively becomes a much better language
>> by being less strict about backwards compatibility.
>>
>>
>
>
>
> --
> Best regards,
> Boris Nagaev
>