Perl 7 will run on the same engine, just with other default pragmas.
I asked explicitely.
Compatibility to CPAN is paramount, P7 will have a compatibility flag.
No relation to Raku.
| [reply] |
If that is the case, then how can bareword filehandles be removed? Or are bareword filehandles supported in Perl7 but omitted from "Standard Perl" and our fellow monk WaywardCode was confused?
Backwards compatibility is my largest concern. The idea that even modern Perl can still run the Perl1 testsuite is impressive, far better than most languages have done, and probably a big part of the cause for the failure of Perl6 as Perl. (How it will fare as Raku is yet to be seen.)
Now that I think about it, "promoting" bareword filehandles to packages would solve the ambiguity in the IO syntax, at the price of requiring a full STASH for each global filehandle and some other internal changes, since *foo{IO} would refer to the nameless I/O slot in package foo instead of an I/O slot on a named GLOB foo. This is not so bad, since global filehandles should be rare and typically limited to main scripts, with =IO references being more common in modules and subroutines, although Symbol's geniosym probably would need to become a builtin XSUB. The idea is that a GV would no longer contain an I/O slot, instead associating an I/O slot to each stash.
The package/filehandle conflict is one of the few actual problems with bareword filehandles in Perl, and I believe this change would solve that problem with minimal impact on backwards compatibility. I believe this could also allow barewords to always parse as package names, another ambiguity resolved if package names evaluate to themselves as strings.
| [reply]
[d/l]
[select] |
If that is the case, then how can bareword filehandles be removed? Or are bareword filehandles supported in Perl7 but omitted from "Standard Perl" and our fellow monk WaywardCode was confused?
I believe the situation itself is confusing, and I apologize if I have made it more so by assuming everyone had watched the conference talks already in my first post. Here is what I know:
EDIT: The outline below assumes the worst outcome sometimes, and even I expect events to veer towards sanity as events unfold. Also, I'm not at all against perl changing, but I don't find the particulars given in these announcements very inspiring.
- Sawyer claimed the default settings (when you run perl with no switches or pragmas) in version 7 will change.
- Obviously this will break old scripts unless they are fixed up or they add compatibility pragmas.
- In the talk he says (paraphrasing) if you have bad code that doesn't run against the new defaults and you don't want to change it, you are going to be unhappy, and that's ok.
- He committed to turning on strict and warnings on video, and alluded to several more he'd like to add, such as signatures
- Meanwhile, brian d foy issues an announcement post claiming the likely removals are:
- indirect object notation
- bareword filehandles (except maybe the standard filehandles)
- "fake" multidimensional arrays+hashes
- change the prototype syntax to the new :prototype syntax
- People on p5p are trying to figure out how to make code with prototypes work across the versions. Maybe they will succeed, but the answer isn't obvious.
- Some on p5p are calling for use v7 to enable the features, rather than changing all the defaults, but so far Sawyer says that won't accomplish his goals. If you read also in this mail you can see that at least some on p5p were blindsided by this announcement (or possibly are feigning it, depending on which side of the argument you believe).
- In foy's post, he says "your code should work if it's not a mess." Again, what's with the condescending talk about old code in these announcements. I mean, seriously, what gives!
- Now, v7 is just v5.32 with some settings changed, and you can change them back by adding pragmas. But, the key thing to notice is that they explicitly offer that kind of compatibility for one major version. It's spelled out in the article, and mentioned in the video.
- You might say "well I'll be dead by version 8" but:
- Perl versions before 5 came at a rapid clip
- Sawyer said he was really looking forward to v8, and not in the sense of "my grandkids will love it"
- So in a couple years when they move to v8, until there's clarification, I have to assume we could lose our ability to get back to something resembling perl5 defaults altogether. In the video, Sawyer's example is that in v8 they would completely remove indirect object calls, but nothing was called out as perma-safe.
- Some poor soul left a question on p5p about whether strict would really apply to v7 one-liners, and got no reply since Jun 26.
- Meanwhile, at the same conference where we just heard Sawyer talking about how he is excited to be able to remove things from the language, we get a talk where he unveils a BNF-restricted "Standard Perl" which omits all kinds of additional perl-isms. He says it enforces code that he likes to write, and how he would like to teach the language to new people. Somehow, he did not predict that this would worry people like me. Whether it worries you is up to you.
| [reply]
[d/l]
[select] |
> The package/filehandle conflict is one of the few actual problems with bareword filehandles in Perl,
what about declared subroutines?
Without brackets they become barewords.
I find the whole, 4ish "how do I pass bareword FH to subroutines?" by "referencing of a glob" syntax like \*DATA extremely confusing.
I won't miss them.
I only wished I wouldn't find so many perldocs and modules on CPAN still advertising them in their POD.
And if you still insist on bareword FHs, you can still let a sub return them.
sub FH {
return $fh;
}
| [reply]
[d/l]
[select] |