Your skill will accomplish what the force of many cannot |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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. In reply to Re^5: Modernizing the Postmodern Language?
by jcb
|
|