Let's not break existing scripts.

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Let's not break existing scripts.

Stefan Reich
I would like to put this very clearly: I am very much against the
prospect of Lua 5.2 breaking ANY script written for 5.1.

It's just a pain and it changes the impression of Lua being something
that "just works" to something that "breaks when you upgrade it".

Python did this with Python3 and I am still hating that. "print is now
a function"? Oh please. Let's just break the most widely-used language
construct for no reason.

Python has not been the same since the 2/3 rift was introduced. I
really really really want Lua to avoid this. 5.1 has a huge basis
which is very important to keep sane and working IMO.

Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Alex Marinko
On Thu, Nov 10, 2011 at 4:55 PM, Stefan Reich
<[hidden email]> wrote:

> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.
>
> It's just a pain and it changes the impression of Lua being something
> that "just works" to something that "breaks when you upgrade it".
>
> Python did this with Python3 and I am still hating that. "print is now
> a function"? Oh please. Let's just break the most widely-used language
> construct for no reason.
>
> Python has not been the same since the 2/3 rift was introduced. I
> really really really want Lua to avoid this. 5.1 has a huge basis
> which is very important to keep sane and working IMO.
>
> Stefan
>


I beg to disagree. Of course, breaking the scripts is a nuisance and a
pain, but it allows the developers much more freedom, which results in
better development of the language.
I believe that Lua wouldn't be what it is now if it had always cared
for compatibility with previous versions.
After all, the major changes in Lua do not come so frequently. So, I
think it is worth paying this price (the nuisance) to have a language
that keeps pace with modern requirements.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Stefan Reich
On Thu, Nov 10, 2011 at 4:01 PM, Alex <[hidden email]> wrote:

> After all, the major changes in Lua do not come so frequently. So, I
> think it is worth paying this price (the nuisance) to have a language
> that keeps pace with modern requirements.

There is no connection between these two things.

The nuisance can be removed extremely easily - just keep setfenv.
(Almost?) full compatibility. No downsides.

Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Philippe Lhoste
In reply to this post by Alex Marinko
On 10/11/2011 17:01, Alex wrote:
> I beg to disagree. Of course, breaking the scripts is a nuisance and a
> pain, but it allows the developers much more freedom, which results in
> better development of the language.
> I believe that Lua wouldn't be what it is now if it had always cared
> for compatibility with previous versions.
> After all, the major changes in Lua do not come so frequently. So, I
> think it is worth paying this price (the nuisance) to have a language
> that keeps pace with modern requirements.

Usual answer: if your scripts work well with Lua 5.1, just run them with Lua 5.1...
You can use Lua 5.2 for new scripts. If you really want some new features of 5.2 in
current scripts, I suppose you have to bite the bullet. Probably not much to change,
anyway. There can be a compatibility layer / script (there was, in the past) too.

It always have been the contract with Lua: the language moves on, in small or big jumps,
but doesn't look back... :-)

We don't want the equivalent of Java, full of deprecated methods or classes, with obsolete
designs, because no old jar must break (but even with minor releases, we can have
incompatible changes, I saw some Swing design to break because of a bug fix in the
library...).

--
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --


Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Luiz Henrique de Figueiredo
In reply to this post by Stefan Reich
> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.
>
> It's just a pain and it changes the impression of Lua being something
> that "just works" to something that "breaks when you upgrade it".
>
> Python has not been the same since the 2/3 rift was introduced. I
> really really really want Lua to avoid this. 5.1 has a huge basis
> which is very important to keep sane and working IMO.

You seem to misunderstand the dynamics of Lua. You never just upgrade Lua,
you consider if the new Lua is good for your needs and then adapt to it.
Lua is not like Firefox...

You can keep whatever version of Lua is suitable for your needs *forever*.
Just freeze the source code into your project.
Many people have done just that...

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Luiz Henrique de Figueiredo
In reply to this post by Stefan Reich
> The nuisance can be removed extremely easily - just keep setfenv.
> (Almost?) full compatibility. No downsides.

There was a *huge* discussion about _ENV when it was introduced.
Please read the archives.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Terry Bayne
In reply to this post by Luiz Henrique de Figueiredo


On Thu, Nov 10, 2011 at 10:12, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.
>
> It's just a pain and it changes the impression of Lua being something
> that "just works" to something that "breaks when you upgrade it".
>
> Python has not been the same since the 2/3 rift was introduced. I
> really really really want Lua to avoid this. 5.1 has a huge basis
> which is very important to keep sane and working IMO.

You seem to misunderstand the dynamics of Lua. You never just upgrade Lua,
you consider if the new Lua is good for your needs and then adapt to it.
Lua is not like Firefox...

You can keep whatever version of Lua is suitable for your needs *forever*.
Just freeze the source code into your project.
Many people have done just that...


I completely agree.

Compatibility between different versions of Lua isn't something I have ever worried about.  Generally when I build Lua into a project, the version of Lua used by that product remains static for the lifetime of the product.  The only time I consider upgrading to a newer Lua version is if there is some overriding advantage to doing so.  By this criteria I have never considered "staying current" to be an overriding reason.

It isn't like there is a large body of Lua code which can be used in a multitude of projects.  I currently have 4 projects that use Lua 5.1, and the scripts are NOT, at all, compatible between them.  This is because each project uses Lua in a completely different context.  And it's that flexibility that makes Lua so brilliantly useful.

Just my .02
Terry
Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Axel Kittenberger
In reply to this post by Stefan Reich
I fully disagree. Lua is a cleaner language than the many others,
because it -did- break several times to improve itself. And the
transistion from 5.1 to 5.2 is just a small one compared to the past
evolutionary jumps it did. You are just recently aboard in a 18 year
old language that did quite well so far. Might take more a humble
approach until we know everything better? :-)

On Thu, Nov 10, 2011 at 4:55 PM, Stefan Reich
<[hidden email]> wrote:

> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.
>
> It's just a pain and it changes the impression of Lua being something
> that "just works" to something that "breaks when you upgrade it".
>
> Python did this with Python3 and I am still hating that. "print is now
> a function"? Oh please. Let's just break the most widely-used language
> construct for no reason.
>
> Python has not been the same since the 2/3 rift was introduced. I
> really really really want Lua to avoid this. 5.1 has a huge basis
> which is very important to keep sane and working IMO.
>
> Stefan
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Rob Kendrick-2
In reply to this post by Stefan Reich
On Thu, Nov 10, 2011 at 03:55:53PM +0000, Stefan Reich wrote:
> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.

Lua breaking backwards compatibility is exactly why it's not the bloated
quagmire that are Python, Perl and Ruby.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Alex Marinko
In reply to this post by Philippe Lhoste
On Thu, Nov 10, 2011 at 5:11 PM, Philippe Lhoste <[hidden email]> wrote:

> It always have been the contract with Lua: the language moves on, in small
> or big jumps, but doesn't look back... :-)

Absolutely. You could not have used better words.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Petite Abeille
In reply to this post by Stefan Reich

On Nov 10, 2011, at 4:55 PM, Stefan Reich wrote:

> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.

Bah... Lua is not Java... no point in time freezing a language at version 0.1 forever...

Plus, as pointed out, if you don't like the changes in 5.2, stick with 5.1. And live happily forever after.

Also, the breaks are usually spread over two major releases: a given release (say 5.2) deprecates a given feature (say setfenv) and the following one removes it altogether (say 5.3). This give you a rather long lead time to adapt. Or not.

That said, in the specific case of (set|get)fenv, as this can be reimplemented in terms of 5.2's _ENV, why remove it? Why not simply leave it in 5.2, but implement it in terms of _ENV?




Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Peter Cawley
In reply to this post by Stefan Reich
On Thu, Nov 10, 2011 at 4:10 PM, Stefan Reich
<[hidden email]> wrote:
> The nuisance can be removed extremely easily - just keep setfenv.
> (Almost?) full compatibility. No downsides.

Although environments are the biggest change, they are not the only
source of incompatibility:
Any 5.1 script which tries to load bytecode will not be compatible
with 5.2, as the bytecode instructions changed.
Any 5.1 script which uses a local variable called _ENV (unlikely I
admit) will in all likelihood not be compatible with 5.2.
Any 5.1 script which assumes that function closures will always be
distinct will not be compatible with 5.2.
Any 5.1 script which depended on exact wording of error messages will
not be compatible with 5.2.
etc.

It is also impossible to write setfenv in 5.2 in such a way as to work
with bytecode chunks whose debug information has been stripped.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Luiz Henrique de Figueiredo
In reply to this post by Petite Abeille
> That said, in the specific case of (set|get)fenv, as this can be reimplemented in terms of 5.2's _ENV, why remove it? Why not simply leave it in 5.2, but implement it in terms of _ENV?

Because forcing those who are interested in 5.2 to rethink their use of setfenv
can lead to better programs. I mean, we expect that in many cases programs
will be clearer with _ENV instead of setfen, even if this means that they
have to be partially rewritten.

All this has been discussed to death before, so I think we''d better drop it.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Roberto Ierusalimschy
In reply to this post by Peter Cawley
> It is also impossible to write setfenv in 5.2 in such a way as to work
> with bytecode chunks whose debug information has been stripped.

Even with debug information it seems impossible to write a setfenv in 5.2
that will be fully compatible with 5.1. (There is a nice implementation
around, but it is too complex for several common cases and yet does not
cover some corner cases.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Paul E. Merrell, J.D.
In reply to this post by Philippe Lhoste
On Thu, Nov 10, 2011 at 8:11 AM, Philippe Lhoste <[hidden email]> wrote:
> It always have been the contract with Lua: the language moves on, in small
> or big jumps, but doesn't look back... :-)

I have no issue with that as far as stand-alone Lua is concerned. But
when you've got Lua embedded in an app that has umpteen thousand
users, incompatibilities between Lua versions can become an upgrade
show-stopper.

Best regards,

Paul

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Dirk Laurie-2
In reply to this post by Stefan Reich
2011/11/10 Stefan Reich <[hidden email]>:

> I would like to put this very clearly: I am very much against the
> prospect of Lua 5.2 breaking ANY script written for 5.1.
>
> It's just a pain and it changes the impression of Lua being something
> that "just works" to something that "breaks when you upgrade it".
>
> Python did this with Python3 and I am still hating that. "print is now
> a function"? Oh please. Let's just break the most widely-used language
> construct for no reason.
>
> Python has not been the same since the 2/3 rift was introduced. I
> really really really want Lua to avoid this. 5.1 has a huge basis
> which is very important to keep sane and working IMO.
>

The difference between Python and Lua is this:

aptitude -s remove python2.7 | grep 'will be freed'
… After unpacking 9,728 kB will be freed.

aptitude -s remove lua5.1 | grep 'will be freed'
… After unpacking 315 kB will be freed.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Petite Abeille
In reply to this post by Peter Cawley

On Nov 10, 2011, at 6:20 PM, Peter Cawley wrote:

> It is also impossible to write setfenv in 5.2 in such a way as to work
> with bytecode chunks whose debug information has been stripped.

Why? _ENV is always the first upvalue, no? No need to look it up by name, no? Its position will suffice, no?


Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Peter Cawley
On Thu, Nov 10, 2011 at 5:58 PM, Petite Abeille
<[hidden email]> wrote:
>
> On Nov 10, 2011, at 6:20 PM, Peter Cawley wrote:
>
>> It is also impossible to write setfenv in 5.2 in such a way as to work
>> with bytecode chunks whose debug information has been stripped.
>
> Why? _ENV is always the first upvalue, no? No need to look it up by name, no? Its position will suffice, no?

Only for top-level chunks. Functions within them can have _ENV at any
position, or not at all.

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Duncan Cross
In reply to this post by Petite Abeille
On Thu, Nov 10, 2011 at 5:58 PM, Petite Abeille
<[hidden email]> wrote:
>
> On Nov 10, 2011, at 6:20 PM, Peter Cawley wrote:
>
>> It is also impossible to write setfenv in 5.2 in such a way as to work
>> with bytecode chunks whose debug information has been stripped.
>
> Why? _ENV is always the first upvalue, no? No need to look it up by name, no? Its position will suffice, no?

No, no and no. :)

_ENV is only the first upvalue for a function that was compiled from a
top-level source code chunk. Functions *in general*, i.e. also
including functions defined inside a chunk or other function, may have
_ENV at a different position, or even not at all.

This has been discussed before:
http://lua-users.org/lists/lua-l/2011-01/msg00377.html

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: Let's not break existing scripts.

Petite Abeille
In reply to this post by Roberto Ierusalimschy

On Nov 10, 2011, at 6:31 PM, Roberto Ierusalimschy wrote:

>  (There is a nice implementation
> around, but it is too complex for several common cases and yet does not
> cover some corner cases.)

I assume you are referring to Sergey Rhozenko's implementation using debug.upvaluejoin?

http://lua-users.org/lists/lua-l/2011-05/threads.html#00124

Care to elaborate about these corner cases?


12