Compatibility with perl 5
Mark J. Reed
> Perl 6, we are promised, will try to run "legacy" code unchanged. How
> will it spot such legacy code?
My understanding has been that perl6 will assume a program is Perl 5 unless
it sees a Perl 6 keyword such as 'module' or 'class'.
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
David Cantrell
pumpking) about making perl5 code forward-compatible with perl6. A
quick look through the mailing list archives didn't turn up anything
obvious, and I don't recall any mechanism being presented in any of the
Apocalypses, so ...
Perl 6, we are promised, will try to run "legacy" code unchanged. How
will it spot such legacy code? Doing this reliably is a hard problem,
but we can make it easier. I suggest that people put:
use perl5;
near the top of their perl programs, scripts and modules. This would be
a clear indicator to the perl6 compiler that this is a perl5 program
without it having to do any complicated and error-prone heuristics. And
it could be implemented really easily in perl5 with no changes to the
core at all:
package perl5;
"i don't do anything yet";
If such a null-op pragma were to go into the next perl 5.8.x release
people could start preparing their existing code for perl 6 right now.
Which is surely a Good Thing. And of course if the pragma were to also
be available to download seperately from the CPAN people still using
older 5.x releases could still use it.
--
David Cantrell
Juerd
> Perl 6, we are promised, will try to run "legacy" code unchanged. How
> will it spot such legacy code? Doing this reliably is a hard problem,
> but we can make it easier. I suggest that people put:
> use perl5;
Why change what already works?
use 5;
no 6;
It could be a special case: not throwing a fatal exception, but instead
changing the grammar to a Perl 5 compatible one.
Juerd
Matthew Walton
> On 2004-04-13 at 13:16:02, David Cantrell wrote:
>
>>Perl 6, we are promised, will try to run "legacy" code unchanged. How
>>will it spot such legacy code?
>
>
> My understanding has been that perl6 will assume a program is Perl 5 unless
> it sees a Perl 6 keyword such as 'module' or 'class'.
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
That's assuming my understanding of hash subscripting and variable
declarations in Perl 6 is even slightly correct, of course.
David Cantrell
> David Cantrell skribis 2004-04-13 13:16 (+0100):
> > Perl 6, we are promised, will try to run "legacy" code unchanged. How
> > will it spot such legacy code? Doing this reliably is a hard problem,
> > but we can make it easier. I suggest that people put:
> > use perl5;
> Why change what already works?
> use 5;
> no 6;
But "no VERSION" does not work, at least in 5.8.3:
david@bytemark:~$ cat foo
use 5;
no 6;
print "version 5, not version 6\n";
david@bytemark:~$ perl foo
syntax error at foo line 2, near "no 6;"
Execution of foo aborted due to compilation errors.
and my discussion with Nicholas didn't lead me to believe that it would
work in the upcoming 5.8.4 either.
--
David Cantrell | http://www.cantrell.org.uk/david
All principles of gravity are negated by fear
-- Cartoon Law V
Thomas A. Boyer
> Mark J. Reed wrote:
>
>> On 2004-04-13 at 13:16:02, David Cantrell wrote:
>>
>>> Perl 6, we are promised, will try to run "legacy" code unchanged. How
>>> will it spot such legacy code?
>>
>>
>>
>> My understanding has been that perl6 will assume a program is Perl 5
>> unless
>> it sees a Perl 6 keyword such as 'module' or 'class'.
>
>
> That could be problematic, because if Perl 6 sees something like:
>
> my %myhash;
> %myhash{'foo'} = 'bar';
>
>
> Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl
6 keyword (such as 'module' or 'class'), as Mark said.
=thom
Reality is that which, when you stop believing it, doesn't go away.
-Philip K. Dick
Matthew Walton
> Matthew Walton wrote:
>> That could be problematic, because if Perl 6 sees something like:
>>
>> my %myhash;
>> %myhash{'foo'} = 'bar';
>>
>>
>> Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
>
>
> It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl
> 6 keyword (such as 'module' or 'class'), as Mark said.
But then trying to process that as Perl 5 will result in an error. This
doesn't seem particularly sane to me. Will we have to say
use 6;
on all Perl 6 programs to avoid this kind of thing?
Forgive me if I'm missing something obvious here.
Luke Palmer
> A few days ago I briefly discussed with Nicholas Clark (current perl 5.8
> pumpking) about making perl5 code forward-compatible with perl6. A
> quick look through the mailing list archives didn't turn up anything
> obvious, and I don't recall any mechanism being presented in any of the
> Apocalypses, so ...
Well, there is one, as far as I understand it. Your "use perl5;" is
spelled "package". That is, perl will assume Perl 6 unless it sees
"package SomethingOrOther;" (since Perl 6 calls them "module"s). So, to
force Perl 5 interpretation, use:
package main;
Luke
Dan Sugalski
You're not, and there is no guaranteed universal heuristic. Being
explicit, via command line switches or executable names, is the
prudent way to go.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Thomas A. Boyer
> Thomas A. Boyer wrote:
>
>> Matthew Walton wrote:
>>
>>> That could be problematic, because if Perl 6 sees something like:
>>>
>>> my %myhash;
>>> %myhash{'foo'} = 'bar';
>>
>> It's going to think 'ahah', perl 5'. Because it doesn't contain any
>> Perl 6 keyword (such as 'module' or 'class'), as Mark said.
>
> But then trying to process that as Perl 5 will result in an error.
> This doesn't seem particularly sane to me. Will we have to say
>
> use 6;
>
> on all Perl 6 programs to avoid this kind of thing?
>
> Forgive me if I'm missing something obvious here.
>
The original question was "how do I label my code as Perl 5?" The
correct answer, according to Apocalypse 1, is to start your source with
"package." If you didn't want to put your code in a package, then start
it with "package main".
The other question was "how do I label my code as Perl 6?" The correct
answer, according to Apocalypse 1, is to start your source with "module"
or "class".
Here is the relevant paragraph from the apocalypse:
I hereby declare that a |package| declaration at the front of a
file unambiguously indicates you are parsing Perl 5 code. If
you want to write a Perl 6 module or class, it'll start with
the keyword |module| or |class|. I don't know yet what the exact
syntax of a module or a class declaration will be, but one
thing I do know is that it'll set the current global namespace
much like a |package| declaration does.
=thom
A lot of people become pessimists from financing optimists.
Matthew Walton
> The original question was "how do I label my code as Perl 5?" The
> correct answer, according to Apocalypse 1, is to start your source with
> "package." If you didn't want to put your code in a package, then start
> it with "package main".
>
> The other question was "how do I label my code as Perl 6?" The correct
> answer, according to Apocalypse 1, is to start your source with "module"
> or "class".
>
> Here is the relevant paragraph from the apocalypse:
> I hereby declare that a |package| declaration at the front of a
> file unambiguously indicates you are parsing Perl 5 code. If
> you want to write a Perl 6 module or class, it'll start with
> the keyword |module| or |class|. I don't know yet what the exact
> syntax of a module or a class declaration will be, but one
> thing I do know is that it'll set the current global namespace
> much like a |package| declaration does.
Righty-ho then. That's not actually all that bad, I'm used to starting
files with 'module' in Haskell (where it's not always compulsory but is
a good idea) so I'm sure I can cope with a similar thing in Perl 6.
Thanks
Aaron Sherman
> Here is the relevant paragraph from the apocalypse:
> I hereby declare that a |package| declaration at the front of a
> file unambiguously indicates you are parsing Perl 5 code. If
> you want to write a Perl 6 module or class, it'll start with
> the keyword |module| or |class|. I don't know yet what the exact
> syntax of a module or a class declaration will be, but one
> thing I do know is that it'll set the current global namespace
> much like a |package| declaration does.
So, there are many ways that Perl 6 could tell. Here's a pseudo-code
(because I don't fully know what Perl 6 will look like yet) example that
is disambiguated in many ways:
#!/usr/bin/perl6
# Use binary "perl6" which defaults to Perl 6 instead of Perl 5.
# This is easy, costs us nothing and does not affect Perl 5
use 6; # Force Perl 6 mode, no need for "no 6" in Perl 5,
# as Perl 6 can safely read "use 5" as "force Perl 5 mode"
class myprog { # encapsulate my program as a class Java-style
# Might need some kind of property to force mainishness
method main(*@args) {
print "Hello world\n";
}
}
Or, if you prefer Perl 5 style:
#!/usr/bin/perl6
use 6;
class null {} # Just for the keyword
print "Hello world\n";
Or, if you prefer C style:
#!/usr/bin/perl6
use 6;
stdout.print("Hello world\n"); # not sure if the invocant will do it
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
David Cantrell
> The original question was "how do I label my code as Perl 5?" The
> correct answer, according to Apocalypse 1, is to start your source with
> "package." If you didn't want to put your code in a package, then start
> it with "package main".
This is something that should be brought to a wider audience cos then
you won't get more people like me wandering in and asking silly
questions. I shall write something up for perlmonks tomorrow.
--
David Cantrell | Official London Perl Mongers Bad Influence
Gregor N. Purdy
people who like to write one-liners and other tiny programs.
Assuming only Perl 6 is installed on your system, if your script
started with:
#!/usr/bin/perl
all the stuff about trying to figure out what version you are using
would have to apply I suppose. But, if you used this, are we saying
you still have to do something else to ensure its treated as Perl 6?
#!/usr/bin/perl6
And, if you did this, you might have to do something else to ensure
it is treated as Perl 5?
#!/usr/bin/perl5
that seems wrong.
Regards,
-- Gregor
--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/
Aaron Sherman
> So, we are moving in a more verbose direction, which is a bummer for
> people who like to write one-liners and other tiny programs.
perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]} s:g/\b<octet>\.<octet>\.<octet>\.<octet>\b/IP ADDR/;' *
No biggie.
> Assuming only Perl 6 is installed on your system, if your script
> started with:
>
> #!/usr/bin/perl
>
> all the stuff about trying to figure out what version you are using
> would have to apply I suppose. But, if you used this, are we saying
> you still have to do something else to ensure its treated as Perl 6?
Yes, because Perl 6 *is* Perl 5, when it wants to be.
> #!/usr/bin/perl6
>
> And, if you did this, you might have to do something else to ensure
> it is treated as Perl 5?
Correct. If you *say* "perl6" and then want to *be* Perl 5, I'm not sure
if a) you could not or b) you would have to throw in something like "use
5".
> #!/usr/bin/perl5
>
> that seems wrong.
Not sure why. That is just short-hand for:
#!/usr/bin/perl
use 5;
I'm not sure, once again, what would happen if you said:
use 5;
use 6;
Either it would give you an error (you really deserve it) or it would
just switch back to Perl 6 mode... the problem arises when you ask,
"what about anything that got parsed in between the two?" Yech.
Brent 'Dax' Royal-Gordon
> On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
>
>>So, we are moving in a more verbose direction, which is a bummer for
>>people who like to write one-liners and other tiny programs.
>
>
> perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]} s:g/\b<octet>\.<octet>\.<octet>\.<octet>\b/IP ADDR/;' *
>
> No biggie.
Curlies aren't used for that anymore. I'd also suggest using an
assertion for a much shorter C<octet> rule:
perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
s:g/\b<octet>\.<octet>\.<octet>\.<octet>\b/IP ADDR/' *
TMTOWTDI, though, and I'm being rather nitpicky.
Personally, I would implement Perl 5 vs. Perl 6 switching as:
1. If argv[0] includes either '5' or '6', use the appropriate version.
2. Parse the program as *both* Perl 5 and Perl 6.
3. Figure out which parses succeeded:
a. If Perl 5 succeeded...
i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
warning should be on by default, but that's open to
negotiation.)
ii. Execute the Perl 6 parse.
b. Else if Perl 6 succeeded, execute the Perl 6 parse.
c. Else...
i. If exactly one of the parses died on an error that
disambiguates between the Perls (e.g. a package statement, a
'use 6'), emit the other's error message.
ii. Otherwise, emit an ambiguity warning and both error messages.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Gregor N. Purdy
didn't intend (and its at least 50% my fault)
----------
In my opinion, starting a script with "#!/usr/bin/perl6" should force
the interpreter to treat it like Perl 6, and if it does anything else
that's just ugly. Similarly, starting a script with "#!/usr/bin/perl5"
should force the interpreter to treat it like Perl 5, and if it does
anything else that's just ugly, too. The only opportunity for
ambiguity is if the script starts with "#!/usr/bin/perl" or no shebang
line.
In that case, maximal backward compatibility dictates that the
interpreter expect Perl 5, although 20 years from now we may wish
Perl 6 was assumed (and maybe by Perl 7 we will assume Perl 6 unless
told otherwise... :)
Personally, I view Perl 6 as such a completely new language (although
still Perlish in spirit, it is very different in other respects), that
I would be perfectly happy to be required to start all my Perl 6
programs with "#!/usr/bin/perl6" instead of "#!/usr/bin/perl", just
the same as I'd start a Python program with "#!/usr/bin/python".
If it turns out that the /usr/bin/perl program is actually just a link
to the same executable as /usr/bin/perl6 but operating with a different
personality, I'm fine with that. Heck, I'd be fine with /usr/bin/python
being a symlink to the same executable, too, and I'd expect it to behave
like a Python interpreter.
I don't see any need to have a program start out as a potentially Perl 5
program and then determine that it should really be thought of as Perl 6
and switch personalities. That is, I don't see a need for this:
#!/usr/bin/perl
use 6;
Since there is no version 6 of the Perl (5) language. Inline::Perl6
aside, there ain't no Perl 6 in the Perl 5 world, even though there are
a few Perl6:: isms.
Now, I do think it would be perfectly fine for a program to start off
as a Perl 6 program and have an embedded chunk that is interpreted as
Perl 5, since that is a feature of Perl 6.
#!/usr/bin/perl6
... # Perl 6 stuff here
use 5; # or, whatever
# Perl 5 stuff here
no 5; # or, whatever
# More Perl 6 stuff here
use python; # you get the idea
...
Regards,
-- Gregor
Gregor N. Purdy
Clever points are relatively high here, but I find the idea of
doing the notionally simultaneous parse uncomfortable. I really
don't want my programs subject to a hidden double parse cost.
Regards,
-- Gregor
Brent 'Dax' Royal-Gordon
> #!/usr/bin/perl6
>
> ... # Perl 6 stuff here
>
> use 5; # or, whatever
>
> # Perl 5 stuff here
>
> no 5; # or, whatever
>
> # More Perl 6 stuff here
>
> use python; # you get the idea
Why conflate the two at all? Perl 5 has two separate syntaxes for
forcing a version and embedding code in a different language:
use 5; # forces Perl < 6
perl_five_code();
use Inline::Perl6 q{ # Ah, the wonders of ponie...
perl_six_code();
};
use Inline::Python q{
python_code()
};
So why not do the same (albeit in a much slicker way) for Perl 6?
use 6; # forces Perl 6+
perl_six_code();
{
use syntax 'perl5'; # switches to Perl 5 syntax
perl_five_code();
}
{
use syntax 'python';
python_code()
} #With the indentation, I think this closes both the Perl and
# the Python block...
Gregor N. Purdy
I think I missed your point. I'll refer to your two code chunks as
(a) and (b). Maybe you are getting at a finer point, though...
What you've said in (a) is pretty much what I hinted about Inline::Perl6
in my message. If you pass it to a Perl 6 interpreter, then it will
probably use that hint to shift into Perl 5 mode (which, fortunately,
is a perfectly respectable thing for a Perl 6 interpreter to do) kind
of as if what you had sent it was really:
#!/usr/bin/perl6
use syntax 'perl5';
...
Any Perl 5 code above your 'use 5' statement that isn't also legal
Perl 6 code, though, would cause the compiler to complain.
I don't see how what you've said in (b) is different from what I've
said, outside the "use 6" which I think shouldn't exist, since
it means nothing to Perl 5 (there is no Perl 5, version 6) and
means nothing to Perl 6 (which has as its lowest version number...
6). So, the code you wrote is Perl 6 with a redundant "use 6"
in it, otherwise in the same vein as what I wrote. If you pass it
to a Perl 5 interpreter, it will choke. If you pass it to a Perl 6
interpreter, life is peachy keen. If you pass it to a Python
interpreter, you get what you deserve :) You have used "use syntax"
which falls under the category of "# or whatever" in my message.
Regards,
-- Gregor
Piers Cawley
I thought that the rule was .pm files were deemed to be Perl 6 unless
they began with 'package', but that anything else was deemed to be Perl
5 unless it began with 'module main'. That way legacy scripts will run
happily and perl 6 scripts can either use a perl6 shebang or start with
'module main'.
--
Beware the Perl 6 early morning joggers -- Allison Randal
Aaron Sherman
> Lets try that again, since I think you parsed my email in a way I
> didn't intend (and its at least 50% my fault)
Hey! *I* have to step up for 50% of the blame now? Where's my lawyer!
;-)
> In my opinion, starting a script with "#!/usr/bin/perl6" should force
> the interpreter to treat it like Perl 6, and if it does anything else
> that's just ugly.
I disagree, but it's a point of aesthetics that I'm willing to concede
as "ugly to some, perhaps many, perhaps most".
> I don't see any need to have a program start out as a potentially Perl 5
> program and then determine that it should really be thought of as Perl 6
> and switch personalities. That is, I don't see a need for this:
>
> #!/usr/bin/perl
> use 6;
I think you meant perl5 there... I will assume you did.
Ok, yes I see your point. Taking from what I said earlier:
#!/usr/bin/perl5
should probably be sugar for:
#!/usr/bin/perl
use 5;
Which means that
#!/usr/bin/perl5
use 6;
translates to:
#!/usr/bin/perl
use 5;
use 6;
Your (p6l) call as to if that should be an error or not. At the very
least, I bow to the wisdom of it being a warning (perhaps optional).
> #!/usr/bin/perl6
>
> ... # Perl 6 stuff here
>
> use 5; # or, whatever
>
> # Perl 5 stuff here
>
> no 5; # or, whatever
Oh please, please, please no!
At the very least, force that to be lexically scoped as Larry suggested,
but I beg of you to not even go that far. Allowing parser re-definition
on the fly is one thing, but providing a handy tool that can be thrown
inline anywhere by people who don't yet "feel comfy" with Perl 6, that
does it all for you, is asking for a level of pain which I'd have to
consult a scorned woman on, cause I know it's gonna be at least a touch
worse than hell trying to maintain that code :-/
The problem is not the syntax, or even really the grammar, but the
semantics... Parrot lets you smooth out the semantics to a subroutine /
class / method / data access level, but to allow such free-form mixing
is gonna be ugly.
My personal feeling is that
use 5;
... anything else ...
use 6;
should be an error, and if you want to write your own support for "My5"
and "My6" which don't give an error, CP6?PAN6?'s doors will be wide
open.
Zsdc
> Personally, I view Perl 6 as such a completely new language (although
> still Perlish in spirit, it is very different in other respects), that
> I would be perfectly happy to be required to start all my Perl 6
> programs with "#!/usr/bin/perl6" instead of "#!/usr/bin/perl", just
> the same as I'd start a Python program with "#!/usr/bin/python".
I second that. It should work, but maybe doesn't have to be required.
Here's an idea how few different disambiguating methods (i.e. perl
binary name, pragmas, command line switches and class-like keywords)
could all work together in a fairly clear and consistent manner. It
requires a little change of C<use VERSION> meaning in Perl 6 but only in
a case where it no longer makes sense anyway.
Perl 6 language is not backwards compatible with Perl 5, so C<use 5> in
Perl 6 should not just mean "Perl v5.0.0 or higher required" like it
does now, but rather "v5.0.0 or higher, but lower than v6.0.0". C<use 5>
and C<use 6> should disambiguate between Perl 5 and 6 in a program run
by perl 6 interpreter.
C<package> just implies C<use 5>
C<class> et al implies C<use 6>
There is already a command line switch for one-liners "-M6" which works
as it should, without any changes to perl 5:
$ perl -M6 -e 'print "ok"'
Perl v6.0.0 required--this is only v5.6.1, stopped (did you mean v6.0.0?).
BEGIN failed--compilation aborted.
(There might be a new switch "-6" introduced, which could mean "-M6" for:
perl -6e '...'
or maybe even "-6" could mean "-M6 -e" so this would work:
perl -6 '...'
making the "-6" a Perl 6 equivalent to "-e" which itself would always
introduce Perl 5 code, allowing all of the existing one-liners to keep
working. In any way, simple "perl -e" should default to Perl 5.)
When the perl binary name ends with a version number, the -MVERSION
might be implied, so "perl6" or "p6" (I'd love perl6 to have p6 as a
standard link) would mean "perl -M6" much like egrep is the same as
"grep -E".
(It is not enough to match a digit "6" at the end, since perl-5.6 should
mean "perl -M5.6" and not "perl -M6" but /(\d+(?:\.\d+)*)$/ (perl5-style
regex) should be ok.)
The most important thing would be that all of this different ways of
switching between Perl 5 and 6 could consistently work as "use VERSION"
(maybe giving a warning in the implicit "package" and "class" cases to
catch errors in Perl 6, but maybe not) so this pathological case:
#!/usr/bin/p6 -M5
class main;
# A
use 5;
# B
would be exactly equivalent to:
#!/usr/bin/perl
use 6; # from the binary name
use 5; # from the -M5
use 6; # from "class"
class main;
# A
use 5;
# B
Now, it might be debatable whether the above code should be allowed or
not. Maybe not. Maybe only one 5/6 disambiguation should be allowed, or
all of them should be consistent in the entire file, or at least after
the first non-C<use VERSION> statement. In any case I think it all could
be just a syntactic sugar for a simple C<use VERSION>.
Such a disambiguated Perl 6 code would not be run by perl5 by accident,
since "use 6" or -M6 will give a correct error, there should be no
binary called perl6 and the -6 switch would not work. The C<use 5> or
-M5 can already be used in Perl 5 programs.
The only change in current "use VERSION" meaning would be to make
versions below 6.0.0 mean "VERSION or higher, but below 6; enter Perl 5
compatibilty mode" (which makes sense anyway, since it is no longer
backwards compatible). This change is not needed in Perl 5.
Of course it would all be optional. In case of no "use VERSION" or
-MVERSION with simple "perl" binary and no class or package, perl would
do whatever is planned to do right now.
I believe it is consistent with all of the current plans and doesn't
need any change to Perl 5. Any comments?
--
ZSDC
Johan Vromans
> ... that I would be perfectly happy to be required to start all my
> Perl 6 programs with "#!/usr/bin/perl6" instead of
> "#!/usr/bin/perl",
Ten years ago I was perfectly happy to start all my perl programs with
/usr/bin/perl5. Today, I would be quite unhappy if I *still* needed to
do it that way.
-- Johan
Aaron Sherman
Of course, and you should not have to. That's why, in absence of any
other tricks, "perl" would try to figure out what you meant to do, but
you CAN be explicit.
I would not be happy about the long-term re-naming of the perl binary,
because that entrenches "perl6" as the name of a program (ask the old
gcc 2.0 guys why that's a bad idea...), but if that's just one of
several options (like my current "/usr/bin/perl5.8.3"), then it seems
like a good thing.
I'll probably continue to write:
#!/usr/bin/perl
use 6;
and add:
use 5;
to my existing Perl 5 programs that I don't have time to convert. That
doesn't mean it's the only way to do it.
Larry Wall
: Ten years ago I was perfectly happy to start all my perl programs with
: /usr/bin/perl5. Today, I would be quite unhappy if I *still* needed to
: do it that way.
In general it's probably a lousy idea to rely on #!/usr/bin/perl6 to
select language since you want the version number to select the
version of Parrot you're running, not the version of Perl.
One thing that occurred to me over the weekend is that we could fix all
the one-liners using a similar strategy to the package/module/class
switch. It would be a (roughly) zero growth option to simply
switch to :x syntax for command-line switches instead of -x syntax.
Any program that uses colon switches instead of minus switches would
then automatically be assumed to be in Perl 6.
So maybe a minimal Perl 6 marker would be something like
#!/usr/bin/perl :
#!/usr/bin/perl ::
#!/usr/bin/perl :6
Larry
Simon Cozens
> It would be a (roughly) zero growth option to simply
> switch to :x syntax for command-line switches instead of -x syntax.
And POSIX be damned!
--
A person is smart. People are dumb, panicky dangerous animals and you know it.
- Agent J, Men in Black
Larry Wall
: la...@wall.org (Larry Wall) writes:
: > It would be a (roughly) zero growth option to simply
: > switch to :x syntax for command-line switches instead of -x syntax.
:
: And POSIX be damned!
And maybe we should rename POSIX to NEGIX while we're at it...
Larry
Rod Adams
>In general it's probably a lousy idea to rely on #!/usr/bin/perl6 to
>select language since you want the version number to select the
>version of Parrot you're running, not the version of Perl.
>
>One thing that occurred to me over the weekend is that we could fix all
>the one-liners using a similar strategy to the package/module/class
>switch. It would be a (roughly) zero growth option to simply
>switch to :x syntax for command-line switches instead of -x syntax.
>Any program that uses colon switches instead of minus switches would
>then automatically be assumed to be in Perl 6.
>
>So maybe a minimal Perl 6 marker would be something like
>
> #!/usr/bin/perl :
> #!/usr/bin/perl ::
> #!/usr/bin/perl :6
>
>Larry
>
>
>
>
Uhm... What exactly is wrong with
#!/usr/bin/perl -M6
?
-- Rod
Corris Randall
why not add a -6 perl flag:
perl -6 foo.pl
perl -6e 'print "yahoo\n"'
-corris
On Apr 26, 2004, at 11:09 AM, Juerd wrote:
> Jonathan Scott Duff skribis 2004-04-26 13:02 (-0500):
>> I know this sounds slightly irrational but I don't like using shifted
>> characters to offset my command line switches. Also, that colon seems
>> *way* overloaded. :-) How about = instead?
>
> Overloaded, but similar to :pairs and s:modifiers.
>
>> #!/usr/bin/perl =
>> #!/usr/bin/perl =6
>
> Feels like something is missing. Like a LHS.
>
> I like - for command line switches.
>
>
> Juerd
Jonathan Scott Duff
> One thing that occurred to me over the weekend is that we could fix all
> the one-liners using a similar strategy to the package/module/class
> switch. It would be a (roughly) zero growth option to simply
> switch to :x syntax for command-line switches instead of -x syntax.
> Any program that uses colon switches instead of minus switches would
> then automatically be assumed to be in Perl 6.
I know this sounds slightly irrational but I don't like using shifted
characters to offset my command line switches. Also, that colon seems
*way* overloaded. :-) How about = instead?
#!/usr/bin/perl =
#!/usr/bin/perl =6
Although perl =P =i.bak =le '...' does look a little strange. But
double the dashes for double the fun! This is perl 6! :-)
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Juerd
> characters to offset my command line switches. Also, that colon seems
> *way* overloaded. :-) How about = instead?
Overloaded, but similar to :pairs and s:modifiers.
Randal L. Schwartz
Larry> It would be a (roughly) zero growth option to simply
Larry> switch to :x syntax for command-line switches instead of -x syntax.
Larry> Any program that uses colon switches instead of minus switches would
Larry> then automatically be assumed to be in Perl 6.
Boy, when Larry says "I get the colon", he really had plans for it.
:-)
Perl8 will look like:
:::: :: :::::::: : : :::::: :: ::::::::::: :::::;
(note the semicolon line terminator, to be replaced by a colon in Perl9).
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Randy W. Sims
ick
>>
> Uhm... What exactly is wrong with
>
> #!/usr/bin/perl -M6
What is wrong with a pragma
use lang perl => 6;
where the version is optional? This will still work on the commandline:
perl -Mlang,perl,6 -e 'blah'
it will also work in a file to allow (possibly in the future) embedding
other languages or parrot assembler. It's unambiguous. It could also
allow hooks for Inline::* modules to be called in the same consistent way.
Randy.