Front page | perl.perl5.porters |
Postings from July 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Paul "LeoNerd" Evans
Date:
July 3, 2020 19:34
Subject:
Re: Announcing Perl 7
Message ID:
20200703203411.2059a434@shy.leonerd.org.uk
On Fri, 3 Jul 2020 14:00:39 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:
> > On Jul 3, 2020, at 1:30 PM, Paul LeoNerd Evans
> > <leonerd@leonerd.org.uk> wrote:
> >
> > Mmm... That's another exciting question I hadn't considered.
> >
> > * The contents of a -e or -E commandline argument
>
> I think that does need to be discussed. It may be that -e needs to be
> v5 and deprecated in 7 in favor of -E which uses the v equal to the
> version of perl that invoked it.
Commandline is quite an interesting case, but there's two parts to it:
* Developers/users running "perl" on their $PATH
* Existing system scripts/etc.. that want to invoke /usr/bin/perl on
some small fragment
I think in the former case the user has chosen their perl by $PATH,
whereas system scripts are going to be quite different. It may be that
we'd have to tie the choice onto a binary name - /usr/bin/perl5 vs
perl7 or something else of that nature.
At very worst, there's always a -5 or -7 flag; I note they're currently
free:
$ perl -7
Unrecognized switch: -7 (-h will show valid options).
> > * A string given to eval()
>
> I don't see the problem. $^H inherits from the scope it comes out of
> right? so eval should follow the same rules as the line it was
> invoked from unless it changes them, right?
Yes; the more I think about it you're right there. An eval() has always
inherited the feature pragmata from its surrounding environment, so
that can just continue to happen exactly as before.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next