Re: Compatibility with perl 5
On Thu, Apr 15, 2004 at 07:23:28PM +0200, Johan Vromans wrote: : 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
Re: Compatibility with perl 5
[EMAIL PROTECTED] (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! -- A person is smart. People are dumb, panicky dangerous animals and you know it. - Agent J, Men in Black
Re: Compatibility with perl 5
On Mon, Apr 26, 2004 at 06:48:56PM +0100, Simon Cozens wrote: : [EMAIL PROTECTED] (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
Re: Compatibility with perl 5
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
Re: Compatibility with perl 5
Larry Wall wrote: 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
Re: Compatibility with perl 5
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
Re: Compatibility with perl 5
Larry == Larry Wall [EMAIL PROTECTED] writes: 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 [EMAIL PROTECTED] 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!
Re: Compatibility with perl 5
On 4/26/2004 2:16 PM, Rod Adams wrote: Larry Wall wrote: 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 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.
Re: Compatibility with perl 5
On Wed, 2004-04-14 at 21:23, Gregor N. Purdy wrote: 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. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compatibility with perl 5
Gregor N. Purdy wrote: 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 Cuse 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 Cuse 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. Cuse 5 and Cuse 6 should disambiguate between Perl 5 and 6 in a program run by perl 6 interpreter. Cpackage just implies Cuse 5 Cclass et al implies Cuse 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-Cuse VERSION statement. In any case I think it all could be just a syntactic sugar for a simple Cuse 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 Cuse 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
Re: Compatibility with perl 5
Gregor N. Purdy [EMAIL PROTECTED] writes: ... 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
Re: Compatibility with perl 5
On Thu, 2004-04-15 at 13:23, Johan Vromans wrote: Gregor N. Purdy [EMAIL PROTECTED] writes: ... 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. 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. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compatibility with perl 5
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. 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 On Tue, 2004-04-13 at 08:12, Luke Palmer wrote: David Cantrell writes: 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 modules). So, to force Perl 5 interpretation, use: package main; Luke -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
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/\boctet\.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.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compatibility with perl 5
Aaron Sherman wrote:
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/\boctet\.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 Coctet rule:
perl6 -i.bak -ple 'rule octet {(\d1,3)($1256)}
s:g/\boctet\.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 [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Compatibility with perl 5
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)
--
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
On Wed, 2004-04-14 at 12:59, Aaron Sherman wrote:
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/\boctet\.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.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
Brent --
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
On Wed, 2004-04-14 at 18:51, Brent 'Dax' Royal-Gordon wrote:
Gregor N. Purdy wrote:
#!/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 Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Compatibility with perl 5
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'. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Compatibility with perl 5
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'?
That's assuming my understanding of hash subscripting and variable
declarations in Perl 6 is even slightly correct, of course.
Re: Compatibility with perl 5
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; It could be a special case: not throwing a fatal exception, but instead changing the grammar to a Perl 5 compatible one. Juerd
Re: Compatibility with perl 5
On Tue, Apr 13, 2004 at 02:27:08PM +0200, Juerd wrote: 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: [EMAIL PROTECTED]:~$ cat foo use 5; no 6; print version 5, not version 6\n; [EMAIL PROTECTED]:~$ 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
Re: Compatibility with perl 5
Matthew Walton wrote:
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
Re: Compatibility with perl 5
Thomas A. Boyer wrote:
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.
Re: Compatibility with perl 5
David Cantrell writes: 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 modules). So, to force Perl 5 interpretation, use: package main; Luke
Re: Compatibility with perl 5
At 4:07 PM +0100 4/13/04, Matthew Walton wrote:
Thomas A. Boyer wrote:
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.
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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Compatibility with perl 5
Matthew Walton wrote:
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.
Re: Compatibility with perl 5
Thomas A. Boyer wrote: 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
Re: Compatibility with perl 5
On Tue, 2004-04-13 at 11:16, Thomas A. Boyer wrote:
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([EMAIL PROTECTED]) {
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 [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compatibility with perl 5
On Tue, Apr 13, 2004 at 09:16:21AM -0600, Thomas A. Boyer wrote: 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
