On Wed, Jun 4, 2008 at 9:09 AM, Roland Giersig [EMAIL PROTECTED] wrote:
batlh yiHegh SuvwI'mo! yIcheghbe' lujwI'mo'!
Die honorably as a warrior! Do not return as a looser!
Not quite. nounmo' means because of the noun, so the above says
something like 'die because of the warrior', 'return
On Wed, Jun 04, 2008 at 10:42:33AM -0400, Mark J. Reed wrote:
: However, I think we are now officially *way* off topic for Perl6...
Not really--a Klingon army is a *parallel* processor, and just because
one Klingon dies doesn't mean the whole army should suddenly die too.
Traditional exception
On Wed, Jun 4, 2008 at 7:21 AM, Mark J. Reed [EMAIL PROTECTED] wrote:
The catch block is lexically contained within the try block, so the
inviolate nature of the curlies remains intact.
thank you.
Mark J. Reed schrieb:
I think the simplest and most Klingonlike expression of the sentiment
is simply this: yIQap pagh yIHegh! (Succeed or die!)
But you could say something like: SuvwI' yIDa: yIHegh! bIlujchugh yIcheghQo'!
(Behave as a warrior: die! If you fail, do not return!)
Thanks for
Larry Wall wrote:
On Wed, Jun 04, 2008 at 10:42:33AM -0400, Mark J. Reed wrote:
: However, I think we are now officially *way* off topic for Perl6...
Not really--a Klingon army is a *parallel* processor, and just because
one Klingon dies doesn't mean the whole army should suddenly die too.
G'day chromatic / p5p / p6l,
Make a list of all possible types of exceptions, define them as roles, and
group them that way. Any given exception can implement multiple roles (:CORE
and :io, for example, or a specialization of that role that also does :USER).
Excellent point. I've been
here }
when ('open') { say Open died }
when (':file') { say Some sort of file error }
...
}
That may be what we have to do for Perl 5, but from the Perl 6
viewpoint it's duplicating information that should derive directly from
the type
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote:
Questions I'm seeking answers to are:
* Is there a document that describes the current p6l exception hierarchy?
My searching skills seem to be impaired today.
* Does anyone have any input they'd like to make before I start fleshing
out
On Mon, Jun 02, 2008 at 12:31:34PM +1000, Paul Fenwick wrote:
G'day p6l and p5p,
I'm currently working on the 'autodie' pragma for Perl 5, which is
essentially 'Fatal' but with lexical scope. It's similar to the 'fatal'
pragma described in S04/Exceptions.
autodie is implementing
G'day p6l and p5p,
I'm currently working on the 'autodie' pragma for Perl 5, which is
essentially 'Fatal' but with lexical scope. It's similar to the 'fatal'
pragma described in S04/Exceptions.
autodie is implementing an exception hierarchy for in-built functions.
Essentially we have
No complaints; resolving ticket.
Patches applied to trunk in r23427 Dec 03 2007.
On Tue Nov 27 19:53:55 2007, [EMAIL PROTECTED] wrote:
I should add that I'll probably have to revise doc/configuration.pod a
bit to impose a rule that Perl 5 %Config may only be 'use-d' in
init::defaults. I'll also have to revise the documentation for
Parrot::Configure::Data::keys
Hi
One recurring problem -- though not the only problem -- is the fact
that to jump-start its understanding of the state of a user's system,
Parrot's Configure.pl relies on the presence of a Perl 5 Config.pm --
and its exported variable %Config -- to perform initial population of
many
On Tue, Nov 27, 2007 at 08:30:38PM -0800, chromatic wrote:
On Tuesday 27 November 2007 19:49:26 James Keenan wrote:
Since this patch affects 16 configuration modules, I would like to
have it tried out on as many platforms as possible. Reports from
Linux and OpenBSD would be particularly
Todd Olson via RT [EMAIL PROTECTED] on 2007/11/28 Wed AM 08:39:24 CST wrote:
One feature I have been exploiting extensively in my Perl 5 installs
is cpan.pm's MyConfig.pm which permits me to overlay Perl's %Config
and to swap sets of config changes in and out with out messing with
the base
-start its understanding of the state of a user's system,
Parrot's Configure.pl relies on the presence of a Perl 5 Config.pm --
and its exported variable %Config -- to perform initial population of
many elements in the Parrot::Configure object's internal data
structure. This is good enough
I should add that I'll probably have to revise doc/configuration.pod a
bit to impose a rule that Perl 5 %Config may only be 'use-d' in
init::defaults. I'll also have to revise the documentation for
Parrot::Configure::Data::keys() to include a caution about avoiding the
'p5Config_' elements.
OTOH
On Tuesday 27 November 2007 19:49:26 James Keenan wrote:
Since this patch affects 16 configuration modules, I would like to
have it tried out on as many platforms as possible. Reports from
Linux and OpenBSD would be particularly helpful, as the init::hints
step for these two OSes calls
On Sunday 20 May 2007 15:45:57 James Keenan wrote:
The patch attached reflects the approach we've been taking over the
last half-year or so in testing the Perl 5 components of Parrot.
Feedback encouraged.
Instead of printing done at the end of code, the *_output_*() test functions
now check
chromatic wrote:
Instead of printing done at the end of code, the *_output_*() test functions
now check that Parrot's exit code is zero. This prevents the test suite from
eating segfaults, as it used to.
If you want to test that Parrot exits with an error given buggy code, use the
On So. 20. Mai 2007, 15:45:56, jkeen !-- x -- at verizon.net wrote:
The patch attached reflects the approach we've been taking over the
last half-year or so in testing the Perl 5 components of Parrot.
Feedback encouraged.
Thanks, patch applied in r18608.
My $0.02:
When hearing
Bernhard Schmalhofer via RT wrote:
When hearing 'executables' I primarily think of compiled programs, e.g.
compiled C-programs. Personally I'd call the *.pl files simple scripts.
Agreed, *.pl isn't an executable. Script works, or program.
Allison
)
+++ docs/tests.pod (working copy)
@@ -141,9 +141,9 @@
At the present time most, if not all, of the programs used to configure, build
and install Parrot are written in Perl 5. These programs take the form of
-executable files (F*.pl) and Perl modules (F*.pm) holding subroutines and
-other
Applied in r18617.
-year or so in testing the Perl 5 components of Parrot.
Feedback encouraged.
kid51
tests.pod
Description: Binary data
On Mar 13, 10:28 am, [EMAIL PROTECTED] wrote:
Thanks for the reply. To be a little more specific, we have internally
tens of thousands of Perl modules. Before running them in production:
we profile these modules, pass them through a circular reference
detector (code that intercepts all
questions easily without a lot more information.
I'd like to get opinions from developers on this list. I'm looking
into this system that executes massive amounts of Perl 5 code on a
Perl 5.8 interpreter. The system burns tons of CPU while running Perl
code, and I'm speculating on ways
On Mar 13, 10:28 am, [EMAIL PROTECTED] wrote:
Thanks for the reply. To be a little more specific, we have internally
tens of thousands of Perl modules. Before running them in production:
we profile these modules, pass them through a circular reference
detector (code that intercepts all
From ozgun:
Inlining replies.
1. What's the environment; Solaris, GNU/Linux, *nix, Windows?
Linux.
2. What hard information do you have on the resources being used? Have
you been able to profile it? Pareto's Law applies surprisingly often.
Tons. In fact, we have more information than
On 12 Mar 2007 14:29:49 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi all,
I'd like to get opinions from developers on this list. I'm looking
into this system that executes massive amounts of Perl 5 code on a
Perl 5.8 interpreter. The system burns tons of CPU while running Perl
code
, but I'm not sure anyone can answer your
questions easily without a lot more information.
I'd like to get opinions from developers on this list. I'm looking
into this system that executes massive amounts of Perl 5 code on a
Perl 5.8 interpreter. The system burns tons of CPU while running
Hi all,
I'd like to get opinions from developers on this list. I'm looking
into this system that executes massive amounts of Perl 5 code on a
Perl 5.8 interpreter. The system burns tons of CPU while running Perl
code, and I'm speculating on ways to improve our throughput (say, 50
billion inst
of Perl 5 code on a
Perl 5.8 interpreter. The system burns tons of CPU while running Perl
code, and I'm speculating on ways to improve our throughput (say, 50
billion inst per module - 10 billion inst/modl) and latency (say, 2
sec/modl - 0.5 secs/modl).
For us, switching to another language
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40774]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40774
Use tcl regular expressions instead of perl 5 ones in
languages/tcl/runtime
, and is much less ugly now. the refactoring has
allowed me to expand on the ability to parse perl match result vars
like '$', '$-[4]', '$1', etc. and that has allowed me to include even
more of the 960 perl 5 tests, in fact, 800 of them. the final 160 are
skipped by the harness because there are too
i've checked in a subset of Perl 5.9.2's regexp tests for PGE to chew
on. for now, i modified the stolen harness to emit PIR. the harness is
currently very ugly... that won't be for long, however, as i'll
refactor it soon.
currently, only 130 of 960 tests are running, as the PIR-producing
harness
the programmer can double-check the translation. A surface-level
translator is always guessing, and doesn't always know it. I dare
say most Perl 5 could be translated to Perl 6 with a series of s///,
but it always be getting stupid just when you want it to be smart.
Gee, it looks like you found
) about the Perl 5 to Perl 6 converter, and it being 40%
completed? ... Larry?
Is anybody working on it? If it's built on something other than PPI, is
there anything I can see, so I can steal any parsing tricks I don't know
of yet. :)
Adam K
On Fri, Mar 25, 2005 at 10:27:53PM +1100, Adam Kennedy wrote:
: Also, I saw another mention recently (possibly on TPF request for
: donations) about the Perl 5 to Perl 6 converter, and it being 40%
: completed? ... Larry?
Well, by one reckoning it's 0% done. At the moment I'm just working
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
[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
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
On Mon, Apr 26, 2004 at 10:44:57AM -0700, Larry Wall wrote:
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
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.
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
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.
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
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
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
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
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
:
#!/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
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
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
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
, 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
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
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
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
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
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
?
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
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
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
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
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
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
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
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
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
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
Okay, here's a task for the perl 5 proficient. I may have mentioned
this before, but maybe not.
What we need, or at least could really use, is a script that
automatically generates missing vtable methods for PMCs. Not
defaulting, the way we have now, but actual real working entries
be:
Perl-5 or Perl-5 like syntax for lightweight scripting
Indeterminate future.
Java or Java-like syntax for objects
The low-level object design will be done by Jan 30th.
An consistent, few-cornor case, executation engine that can handle
circular references and threads
Circular refs
Dan Sugalski writes:
Okay, here's a task for the perl 5 proficient. I may have mentioned
this before, but maybe not.
What we need, or at least could really use, is a script that
automatically generates missing vtable methods for PMCs. Not
defaulting, the way we have now, but actual real
And, out of interest, what is the rate limiting step for this (amount of
coffee given to Dan?)
In large part, yes. Communication bandwidth and latency is also an
issue -- there are things that we could clear up in a week if we got
a half-dozen of the interested parties in a room with lots
]
Now - an ideal world would be:
Perl-5 or Perl-5 like syntax for lightweight scripting
Java or Java-like syntax for objects
An consistent, few-cornor case, executation engine that can handle
circular references and threads
Embeddable in Apache like mod_perl
perl6 as a language
objects and Oh, look, this thingie... it's an
object too! type objects are easily doable.
Currently I'm not seeing any technical reason for perl 5 style
objects to be anything other than, well, perl 5 style objects.
Something could come up, I suppose, but I'd not expect
On Sun, Dec 21, 2003 at 04:55:28AM -, PerlDiscuss - Perl Newsgroups and mailing
lists wrote:
: When the official release of Perl 6 is released and I start to write some
: Perl 6 programs using Perl 5 modules, will I get any errors? How will this
: be handled? Will all of the Perl 5 modules
When the official release of Perl 6 is released and I start to write some
Perl 6 programs using Perl 5 modules, will I get any errors? How will this
be handled? Will all of the Perl 5 modules have to be ported over and
converted to Perl 6 code? Can I have a basic perl6.pl file while using
PerlDiscuss - Perl Newsgroups and mailing lists wrote:
When the official release of Perl 6 is released and I start to write some
Perl 6 programs using Perl 5 modules, will I get any errors? How will this
be handled? Will all of the Perl 5 modules have to be ported over and
converted to Perl 6 code
Larry discounted RFC261 in A5, but I think there's some good in it. The
biggest problem is not that it's hard to do in Perl6, but that 80-90% of
it is ALREADY done in Perl5! Once you peel away that portion of the RFC,
you get to Perl5's limitations and what Perl6 might do to support these
At 11:12 AM +0100 1/2/70, James A Duncan wrote:
Morning (BST) all,
I've started work on B::Parrot, which is a Perl 5 to Parrot
translation engine. Its very basic at the moment, but I've got it
successfully translating things like:
my $perliv = 10;
my $perlpv = \n;
print $perliv;
print
Dan Sugalski [EMAIL PROTECTED] writes:
At 11:12 AM +0100 1/2/70, James A Duncan wrote:
Morning (BST) all,
I've started work on B::Parrot, which is a Perl 5 to Parrot
translation engine. Its very basic at the moment, but I've got it
successfully translating things like:
my $perliv = 10;
my
comes from. Perl6::Tokenise is
sufficiently flexible that it can be turned into a Perl 5 tokeniser with
minimal changes to the ruleset.
Indeed, it should really be changed so that the ruleset is part of the
tokeniser object, so you can slot in and out rulesets as necessary. (And it
will be necessary
On 4/4/02 10:21 pm, in article
[EMAIL PROTECTED], Rafael Garcia-Suarez
[EMAIL PROTECTED] wrote:
James A Duncan wrote in perl.perl6.internals :
I've started work on B::Parrot, which is a Perl 5 to Parrot translation
engine. Its very basic at the moment, but I've got it successfully
Melvin Smith wrote in perl.perl6.internals :
It sounds like what you are embarking on is a compiler implementation
with a full grammar, etc. Right?
Not at all, he wants to reuse the perl 5 parser to generate parrot
opcodes from perl 5 opcodes.
I also remember there was work already
On Fri, Apr 05, 2002 at 12:02:19AM +0100, James Duncan wrote:
The biggest issue that I can immediately foresee is Perl 5 Regular
Expressions. Currently they occupy (I think) one op in perl. This is a
problem, as also not on my Fun Things To Do list is grokking the regex
engine
Morning (BST) all,
I've started work on B::Parrot, which is a Perl 5 to Parrot translation
engine. Its very basic at the moment, but I've got it successfully
translating things like:
my $perliv = 10;
my $perlpv = \n;
print $perliv;
print $perlpv;
into working, assemble-able parrot code
James A Duncan wrote in perl.perl6.internals :
I've started work on B::Parrot, which is a Perl 5 to Parrot translation
engine. Its very basic at the moment, but I've got it successfully
translating things like:
my $perliv = 10;
my $perlpv = \n;
print $perliv;
print $perlpv
At 11:12 AM 1/2/1970 +0100, James A Duncan wrote:
Morning (BST) all,
I've started work on B::Parrot, which is a Perl 5 to Parrot translation
engine. Its very basic at the moment, but I've got it successfully
translating things like:
my $perliv = 10;
my $perlpv = \n;
print $perliv;
print
Nathan Wiger [EMAIL PROTECTED] writes:
* Dan Sugalski [EMAIL PROTECTED] [05/10/2001 14:18]:
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definately will happen.
Damn straight. One way or another, perl 6 will eat perl 5 code close
that does them little good unless they know what syntax to
migrate to, and that the syntax is supported in some fashion in 5.8.
(And if we start adding a bunch of Perl 6 keywords into Perl 5, there
are issues with that as well.)
Larry
On some date someone wrote:
: option in (say) perl5.8 which would allow folk to find typeglobs etc,
: and adjust code in advance.
It should be possible to do most of this externally as a B module.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality
* Dan Sugalski [EMAIL PROTECTED] [05/10/2001 14:18]:
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definately will happen.
Damn straight. One way or another, perl 6 will eat perl 5 code close to
painlessly. (Typeglobs, perhaps
At 02:58 PM 5/10/2001 -0700, Nathan Wiger wrote:
* Dan Sugalski [EMAIL PROTECTED] [05/10/2001 14:18]:
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definately will happen.
Damn straight. One way or another, perl 6 will eat perl 5
I'd just like to make this abundantly clear, since there seems to be
some confusion (and hopefully I'm not the one confused).
*** You will NOT have to rewrite your Perl 5 programs ***
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down
At 10:06 PM 5/10/2001 +0100, Michael G Schwern wrote:
I'd just like to make this abundantly clear, since there seems to be
some confusion (and hopefully I'm not the one confused).
*** You will NOT have to rewrite your Perl 5 programs ***
Perl 6 *will* provide a backwards compatible Perl 5
On Thu, May 10, 2001 at 02:58:50PM -0700, Nathan Wiger wrote:
* Dan Sugalski [EMAIL PROTECTED] [05/10/2001 14:18]:
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definately will happen.
Damn straight. One way or another, perl 6
* Adam Turoff [EMAIL PROTECTED] [05/10/2001 15:20]:
Yes, it has, in Apocolypse 1:
Perl 6 must assume it is being fed Perl 5 code until it knows otherwise.
http://www.perl.com/pub/2001/04/02/wall.html
Yup, I saw that - actually, the discussion I was referencing was
post
201 - 300 of 387 matches
Mail list logo