|
in reply to Re: Back to the __future__
in thread Back to the __future__
Basically the idea is that your module states
use 5.20;
And it will get (lexical) 5.20.x semantics for its code, no matter what version of Perl it runs on. At least to the best of effort that can be made.
The intention is to free Perl code up from backwards compatibility issues in the sense that for example the current implementation of the smartmatch operator ~~ does not make much sense, but code that uses it now will likely expect 5.14 semantics.
The one thing that Jesse has not yet declared is how to specify "I need Perl 5.xx or higher". For example, I have code that declares it wants Perl 5.06 because it wants lexical filehandles. But that same code will (likely) run on any future version of Perl as well, so I don't want to request 5.06 semantics for everything. |
Re^3: Back to the __future__
by JavaFan (Canon) on Aug 19, 2011 at 10:53 UTC
|
First of all, the least version for which this will apply is 5.16. And that's assuming it can be build before that.
But really, what's is the purpose of saying "I need Perl 5.xx or higher"? The entire point of this exercise is to be able to remove features without breaking. The fact that use 5.006; means "I want lexical filehandles" means we have to support lexical filehandles forever, in the same as it's now.
Say, in 5.20 we have a really awesome feature. You get it with use 5.20;. But a year and a half later, it turns out the feature wasn't so awesome, or it can be made better, but only in a way to break backwards compatibility, Jesse's proposal makes it possible. use 5.20; and use 5.22; will give you the awesome feature, use 5.24; won't, or with a changed syntax and/or semantics.
But if people can say "use 5.20 or something newer", it's not going to work. Then we're back to the same backwards compatibility issues we have right now.
Note that Jesse's proposal doesn't imply that use 5.20; means it's going to croak on 5.22 or 5.24. Not at all. It means that 5.22 or 5.24 is going to emulate the 5.20 behaviour. | [reply]
[d/l]
[select] |
|
|
I'm of two minds here - on one hand, I understand that I can only guarantee that the code will behave as I wrote it. On the other hand, I trust Perl more than I trust myself in understanding the features, so I want to state what I know about the code, in the sense of minimum requirements, but otherwise tell Perl "Do whatever you think is correct".
Of course, there will come a point in time when Perl deviates from its behaviour, but I see that as my problem and not as Perls problem. Maybe use v.infinity; would be the proper way to state that I think that the upper bound of Perl version is unknown.
| [reply]
[d/l] |
|
|
On the other hand, I trust Perl more than I trust myself in understanding the features, so I want to state what I know about the code, in the sense of minimum requirements, but otherwise tell Perl "Do whatever you think is correct".
I fail to see the benefit of that.
Suppose we had this scheme already in place, say since 5.8. You specify for a program "oh, give me 5.10 or anything newer, including its changes in behaviour". You did not include use strict;, because your program is doing some tricks that requires it to be off.
Then 5.12 came along, which defaults to enabling strict. Your program now fails to run. Would that have made you happy?
Of course, there will come a point in time when Perl deviates from its behaviour, but I see that as my problem and not as Perls problem.
But it is Perls problem. Backwards compatability has an enormous value. It lowers the bar to write products in Perl. It lowers the bar to upgrade your Perl. Without backwards compatability, Perl would not even have been half so successful as it is now.
But backwards compatability is also holding us back. We keep having to support old features, and new syntax sometimes is convoluted because a more natural way of writing clashes with some obscure, mostly forgotten, syntax. Remember how long it took before // was accepted? The reason it took so long was because it could clash with existing syntax. We would have had // much earlier if we'd had something like Jesses proposal.
| [reply]
[d/l]
[select] |
|
|
|
|
| |
|
what's is the purpose of saying "I need Perl 5.xx or higher"?
That way we can specify a minimum release.
I suggested that particular syntax because it uses existing syntax rather than inventing new, so versions up to and including 5.14 don't barf.
I appreciate that the meaning of the use will change to mean emulate a particular release, I'm querying whether that will be always feasible. If a feature needs to be changed, then being able to support both new and old could make the code even more complex, and might not always be possible every time. I think Jesse said as much in his talk, at least that was the impression I got.
| [reply] |
|
|
| [reply]
[d/l] |
Re^3: Back to the __future__
by Tux (Canon) on Aug 18, 2011 at 14:50 UTC
|
Note that it is by far "done" (yet). There are lots of issues to be discussed before decisions are made.
E.g. the above statement conflicts with the idea that use v5.12.4; can be used to indicate that one needs version 5.12.4 or up because a vital bug was fixed in that version and the script won't work with anything older.
That concept could be solved by using something like use ge5.12.4 (as in greater or equal to 5.12.4, which I suggested to Jesse). That however will not suffice, as you might need 5.12.4 or newer (because of the bugfix) but do not support beyond 5.16.7 (because of syntax change). How would you define ranges? use ge5.12.4, lt5.16.8;?
How will perl "support" ranges (if at all)? Should there be more than one declaration? What if - inside a range - something changed dramatically. What should perl choose to do? Syntax vs Semantics? etc etc.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
|
|
Hmm. This sounds similar to the problem we have with browser-detection as opposed to feature-detection. Wouldn't it be better, instead of saying "I need version 5.20 semantics", to say "I need X semantics", where X is the name of a semantic set. Implementing this feature at this late stage in perl's development would probably require significant work, but would avoid module/script authors having to determine which semantics changed in which versions. If you care about them, you ask for what you want.
| [reply] |
Re^3: Back to the __future__
by davido (Cardinal) on Aug 18, 2011 at 07:21 UTC
|
Given the Perl6 interpreter has a Perl5 mode of operation, would there be Perl5 lexical semantics available to modules that can interact with Perl6 callers? Or is that 'switch' all or nothing?
If the CPAN is Perl5's 'killer application', some interoperability could ease the concerns about beginning new projects in a new language. ...after Christmas comes, of course. ;)
| [reply] |
Re^3: Back to the __future__
by cdarke (Prior) on Aug 19, 2011 at 09:12 UTC
|
use 5.18;
no 5.22;
which would mean "use any release after 5.18, but not 5.22 or higher". | [reply]
[d/l] |
|
|
Help. /me has a hard time parsing that. With Jesse's proposal that would render the second statement useless, as the first already states that you want it the way it is for 5.18. Nothing wrong with that. But in that proposal, you (as a programmer, not as author here) ignore all the stuff that was released after 5.18 so no 5.20; is useless as you already said so.
What I was looking for is about what Corion said. I need at least version X (because an important bug was fixed or some new (at that time) killer feature was being introduced (like Unicode 6.0 in 5.14.1) but I trust perl to have not fucked up in later releases. That is how I always interpreted the use v5.12; syntax.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
|
|
