On Tue, 17 Apr 2001, Tim Bunce wrote:
[...]
That beautiful code will be beautifully _open_ to _external_ extensions.
And that is how I imagine that Perl 5 support should be implemented.
Exactly. I am pretty sure that already at the meeting in Monterey
someone suggested that Perl5 should
Tim Bunce wrote:
If the file doesn't start with Perl 6 thingy then
it's Perl 5. Period.
To mandate the impossible is to mandate failure.
"Nothing can parse perl like Perl."
Why is that?
My reading of Larry's comments is that it won't be "in" our "new
beautiful co
At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote:
On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
People seem to think that telling Perl 5 apart from Perl 6 is trivial.
My reading of Larry's comments is that it will be _made_ trivial at the
file scope level. If the file doesn't
Dan Sugalski writes:
: At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote:
: On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
: People seem to think that telling Perl 5 apart from Perl 6 is trivial.
:
: My reading of Larry's comments is that it will be _made_ trivial at the
: file
On Tue, Apr 17, 2001 at 09:23:56AM -0400, John Porter wrote:
Tim Bunce wrote:
If the file doesn't start with Perl 6 thingy then
it's Perl 5. Period.
To mandate the impossible is to mandate failure.
"Nothing can parse perl like Perl."
Why is that?
Because perl has a bunch
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote:
There are a number of reasons to *not* claim to parse perl 5 code.
*) We won't load any perl 5 XS code
*) We won't be getting the corner cases, and perl5 has a *lot*.
*) It complicates the interpreter if we need to add code to support things
all sorts of bytecode-compiled languages. :)
You want to write the parser for the perl 5 code? (And yes, I do know how
inherently silly that question was... :) I want the runtime to be able to
handle Python too, but that doesn't mean we're going to be shipping a
parser for it.
The problems I
On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote:
I hereby declare that a package declaration at the front of a file
unambiguously indicates you are parsing Perl 5 code.
^^^
Grand. To play devil's advocate here for a moment
of
Perl.)
If the programmer wants perl 5, then he/she/it/they should *use* perl 5.
It's not going to rot.
ii) Because Larry said so, *and* declared how to do it:
I hereby declare that a package declaration at the front of a file
unambiguously indicates you are parsing Perl 5 code. If you
At 05:20 PM 4/16/2001 +0100, Simon Cozens wrote:
On Mon, Apr 16, 2001 at 12:11:41PM -0400, Dan Sugalski wrote:
I hereby declare that a package declaration at the front of a file
unambiguously indicates you are parsing Perl 5 code
On Mon, Apr 16, 2001 at 12:25:15PM -0400, Dan Sugalski wrote:
*cough*
s/parse/interpret/;
Seems a bit of a shame to parse it and then not do anything with it,
especially if we're trying to push Perl 6 as a common language runtime
for running all sorts of bytecode-compiled languages. :)
--
On Mon, Apr 16, 2001 at 12:19:38PM -0700, Peter Scott wrote:
Er, I don't get it. I'm proposing that if perl 6 determines it's been
given perl 5 code, it does "exec perl5 $0". So thereafter it's as though
perl 6 never existed as far as that code is concerned; whatever it wan
Dan Sugalski wrote:
Besides the size and clunkiness issues, there's another problem. String
evals in a perl 5 section of code will expect to be parsed as perl 5, which
kinda precludes the whole "compile perl 5 to bytecode and pass it through
the p526 converter" solution. Ma
At 11:50 AM 4/16/2001 -0700, Nathan Wiger wrote:
Dan Sugalski wrote:
Besides the size and clunkiness issues, there's another problem. String
evals in a perl 5 section of code will expect to be parsed as perl 5, which
kinda precludes the whole "compile perl 5 to bytecode and
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
Or were you espousing the notion that perl 6 programs should be able to
contain sections of perl 5 code? That gives me strange palpitations.
This is what I've been arguing against. Unless I misunderstand (and it
wouldn't be the first time
Dan Sugalski wrote
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
Or were you espousing the notion that perl 6 programs should
be able to contain sections of perl 5 code? That gives me
strange palpitations.
This is what I've been arguing against. Unless I misunderstand
k and work
has been for nothing and we have failed.
People seem to think that telling Perl 5 apart from Perl 6 is trivial.
In certain special cases, yes, such as the "module"/"class" versus
"package" distinction described by Larry, but in the general case that
is no
At 09:47 AM 4/16/2001 -0700, Peter Scott wrote:
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote:
There are a number of reasons to *not* claim to parse perl 5 code.
*) We won't load any perl 5 XS code
*) We won't be getting the corner cases, and perl5 has a *lot*.
*) It complicates the interpreter
At 02:49 PM 4/16/2001 -0500, Jarkko Hietaniemi wrote:
Thinking about the 5-6 migration and coexistence is good and useful,
but since that doesn't advance the Prime Directive, thinking about it
*too* much now or fighting over the niggly details is somewhat wasted
effort.
We have been stuck in a
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS We have been stuck in a sort of Gilbert and Sullivan debate,
DS haven't we? Silly, definitely silly.
o/' perl6 is the very model of a modern major interpreter o/'
:-)
uri
--
Uri Guttman - [EMAIL PROTECTED] --
On Mon, Apr 16, 2001 at 03:23:04PM -0400, Dan Sugalski wrote:
At 12:19 PM 4/16/2001 -0700, Peter Scott wrote:
Or were you espousing the notion that perl 6 programs should be able to
contain sections of perl 5 code? That gives me strange palpitations.
This is what I've been arguing against
On Thu, 5 Apr 2001, John Porter wrote:
Nathan Wiger wrote:
the more compatible
with Perl5 Perl6 is, the more likely it is to be accepted.
I don't believe that's necessarily true.
If Perl6 proves to be a significantly better Perl than Perl5,
people will adopt it, especially if they're
Dave Storrs wrote:
being backwards compatible is unlikely to
_cost_ us adherents and might well gain us some.
Yes, all other things being equal. But will they be?
IOW: at what cost backwards compatibility?
--
John Porter
nds in 6.
Yep, something like this would be cool. But as Dan suggested we'll
probably have to let Larry clarify his intent here. I read it as "it
would be cool to assume that we're getting real Perl 5 code", rather
than as just assuming Perl 5 non-strict policies, but actual Perl 6
co
Nathan Wiger wrote:
the more compatible
with Perl5 Perl6 is, the more likely it is to be accepted.
I don't believe that's necessarily true.
If Perl6 proves to be a significantly better Perl than Perl5,
people will adopt it, especially if they're inclined toward
the Perl philosophy anyway. (And
cool to assume that we're getting real Perl 5 code", rather
than as just assuming Perl 5 non-strict policies, but actual Perl 6
code.
I agree with Ed that, if you think about it, parsing Perl 5 in the Perl
6 detachable-lexer-parser model shouldn't (hopefully) be any harder than
parsing Python
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
On 15 Dec 2000, Randal L. Schwartz wrote:
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven As for special-case rules, I believe that my proposed modification would
Deven REMOVE a special-case semantic rule, at the cost of added
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
If we want the first interesting match, and we're preferring early matches
and short matches, I believe that "bd" is more interesting.
then write a regex that describes that pattern. the pattern is
one b
followed by
On Fri, 15 Dec 2000, Simon Cozens wrote:
On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
Tell me how you can do that without breaking much existing code.
Pssst, Randal, this is Perl 6, not p5p.
well, we do have to translate 95% of that code to Perl 6 without a hitch.
i
On Thu, 14 Dec 2000, Deven T. Corzine wrote:
Here is a simple example: (tested with perl 5.005_03)
$_ = "";
($greedy) = /(b.*d)/; # "" (correct)
($non_greedy) = /(b.*?d)/; # "d" (should be "bd"!)
Does anyone
On Thu, 14 Dec 2000, Nathan Torkington wrote:
Deven T. Corzine writes:
I haven't even SEEN an example where the current behavior is actually
preferable than my proposed behavior, have you? (And I'd expect at least a
FEW, though I suspect there are probably more counterexamples.)
I
On Fri, 15 Dec 2000, Jonathan Scott Duff wrote:
On Fri, Dec 15, 2000 at 01:13:13PM -0500, Deven T. Corzine wrote:
Not at all. I don't want it to keep looking after it finds the first
match. I want it to make sure that match isn't unnecessarily long, if
non-greedy matching was in use.
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven What surprised me was how vigorously people would defend the
Deven status quo, and insist on the correctness of the current
Deven behavior without thinking it through.
No, I thought it through quite completely. As have others.
Deven
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven As for special-case rules, I believe that my proposed modification would
Deven REMOVE a special-case semantic rule, at the cost of added complexity at the
Deven implementation level. (The cost decision of whether that added complexity
"DTC" == Deven T Corzine [EMAIL PROTECTED] writes:
DTC The pattern in question is "b.*?d". Obviously, this matches "b",
DTC followed by something else, followed by "d". What "something
DTC else" should be is the issue at hand. That portion of the regexp
DTC is just ".*?" -- the "."
On Thu, 14 Dec 2000, Jarkko Hietaniemi wrote:
On Thu, Dec 14, 2000 at 04:19:15PM -0700, Nathan Torkington wrote:
Deven T. Corzine writes:
I haven't even SEEN an example where the current behavior is actually
preferable than my proposed behavior, have you? (And I'd expect at least a
affects relatively few regexps.
What surprised me was how vigorously people would defend the status quo,
and insist on the correctness of the current behavior without thinking it
through. Maybe I should have expected this -- it's probably an old debate
people are tired of having. But if there's ever
Please give it a rest. I think everybody got it by now. Everybody
understands how the current implementation works and what the
semantics are, and you disagree with the current semantics. I think
that's the end of story since changing current default semantics is
simply not an option. We
"Deven T. Corzine" [EMAIL PROTECTED] writes:
I've yet to see a concrete example of where the current behavior is
helpful,
What about matching C comments?
($first_comment) = $code =~ m!(/\*.*?\*/)!s;
# (ignore issues with quoted strings in $code
Works correctly under the current
More generally, it seems to me that you're hung up on the description
of "*?" as "shortest possible match". That's an ambiguous
Yup, that's a bit confusing. It's really "start matching as soon as
possible, and stop matching as soon as possible". (The usual greedy
one is, of course, "keep
ld make regex in Perl
entirely unlike the regex in every other language. Not gonna happen.
I've NEVER seen non-greedy matching in any other regular expression system
before Perl 5 introduced it. Ever since then, I've only seen it in other
systems that imitate (or use outright) Perl's regex
I made a mistake in phrasing it this way, because it seemed to suggest that
I thought it was an implementation bug that it returns "d" instead
of "bd". I didn't make it clear that I was trying to approach this as
a purely SEMANTIC question, considered in isolation from the
On 15 Dec 2000, Randal L. Schwartz wrote:
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven As for special-case rules, I believe that my proposed modification would
Deven REMOVE a special-case semantic rule, at the cost of added complexity at the
Deven implementation level.
ed on Perl 4's magic behavior with @'s in
double-quoted strings, yet Perl 5 broke them all with a fatal error during
the compile phase. People survived. They adapted and moved on. Unlike
that incompatibility, this one would probably affect few programs.
I'm likely to give up this battle and move o
, and the "leftmost" behavior is 100% consistent with greedy
matching.
Nope. These are orthogonal, unrelated concpets.
Yet Perl 5 added non-greedy modifiers, changing a fundamental
aspect of every preceding regex system, and still called it a regex...
Whether a match should be minimal or maximal
I wrote:
More generally, it seems to me that you're hung up on the
description of "*?" as "shortest possible match". That's an
ambiguous simplification of what "*?" means. It might better be
described as "match until you find a match for the rest of the
regex" ('d' in your example). If
I want the maximum level of OVERALL consistency for regular expressions as
We're there, thank you very much. "Find a match" is the over-riding
sentiment, the principle semantic. It is completely consistent with
this. You've got greed/nongreed very wrong.
a whole, rather than immutable
On Thu, 14 Dec 2000, James Mastros wrote:
On Thu, Dec 14, 2000 at 04:10:12PM -0500, Deven T. Corzine wrote:
The crux of the problem is that non-greedy qualifiers don't affect the
"earliest match" behavior, which makes the matches more greedy than they
really ought to be.
Right. We've
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
Not at all. I don't want it to keep looking after it finds the first
match. I want it to make sure that match isn't unnecessarily long, if
non-greedy matching was in use. Conceptually (I don't think this would be
a good implementation), you
Really? I haven't taken a survey, but I did ask one co-worker for his
first impression of what the regexp (from my example) would match. Not
being an experienced Perl programmer, but being familiar with regular
expressions, he believed he understood the idea of non-greedy matching.
His
On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
Tell me how you can do that without breaking much existing code.
Pssst, Randal, this is Perl 6, not p5p.
--
"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence." -
y we could. Maybe we shouldn't, but we could do it. Many,
many existing programs depended on Perl 4's magic behavior with @'s in
double-quoted strings, yet Perl 5 broke them all with a fatal error during
the compile phase. People survived. They adapted and moved on.
Red herring.
Unlike
that incom
On Fri, 15 Dec 2000, Tom Christiansen wrote:
Actually, I'm not sure -- it's conceivable that the ending point would ALSO
move inward for a different starting point within the original match. But
the ending point should NEVER be advanced further -- that's where the
"leftmost over nongreedy"
On Fri, 15 Dec 2000, Simon Cozens wrote:
On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
Tell me how you can do that without breaking much existing code.
Pssst, Randal, this is Perl 6, not p5p.
That's why I never suggested fixing it in Perl 5 -- the chance of breaking
Actually, I'm not sure -- it's conceivable that the ending point would ALSO
move inward for a different starting point within the original match. But
the ending point should NEVER be advanced further -- that's where the
"leftmost over nongreedy" rule should apply instead...
Please show us your
On Fri, 15 Dec 2000, Tom Christiansen wrote:
As for special-case rules, I believe that my proposed modification would
REMOVE a special-case semantic rule, at the cost of added complexity at the
implementation level.
What is this alleged "special-case rule" you are talking about?
There
Tom Christiansen writes:
We may have to "agree to disagree".
I shan't be doing that.
I think you should, or at least agree to take it private and report
back to the list once you both come to a decision. Once you've stated
your position twice, there's not really much point in saying it a
l 4's magic behavior with @'s in
double-quoted strings, yet Perl 5 broke them all with a fatal error during
the compile phase. People survived. They adapted and moved on.
Red herring.
Counterexample to the assumption that we can't break existing code by
changing the semantics. It's been done bef
become one. I'd like to make
sure that everyone, Deven, Tom, and the rest of the list, relax and
realize that it's just a programming language.
This _is_ a minor issue. I'm very much looking forward to Perl 6; since
Perl 5 is such a joy to use, I fully expect Perl 6 to be even better. And
I'l
On Fri, 15 Dec 2000, Tom Christiansen wrote:
You can't explain why "d" matches without making reference to the
absolute priority of the leftmost rule. "bd" would still make sense
(locally) without reference to that rule.
Nope. Nope, nope, and nope.
Th8is /d/
That would be a strange regexp, but I never suggested it. I suggested the
regexp /b.*?d/ and pointed out that I believe "bd" is a more intuitive
match than "d". That was the matching text, not the regexp, sorry
if I didn't make that clear.
Fine. What you said is
first
At worst, this should take no more than double the amount of time that the
single pass did, probably less. Hardly a cause to concern ourselves with
the heat death of the universe.
Oh really? We have shown that for the kind of global overall
analysis that you are asking for, that in the general
More generally, it seems to me that you're hung up on the description
of "*?" as "shortest possible match". That's an ambiguous
Yup, that's a bit confusing. It's really "start matching as soon as
possible, and stop matching as soon as possible". (The usual greedy
one is, of course, "keep
Have you thought it through NOW, on a purely semantic level (in isolation
from implementation issues and historical precedent),
I've said it before, and I'll say it again: you keep using
the word "semantic", but I do not think you know what that word means.
--tom
Take. It. To. Private. Email. Please.
I'm going to do better. I'm taking it to /dev/null.
It's not worth my wasting my life over. Nobody
agrees with this guy, so it doesn't matter.
--tom
On Fri, 15 Dec 2000, Tom Christiansen wrote:
At worst, this should take no more than double the amount of time that the
single pass did, probably less. Hardly a cause to concern ourselves with
the heat death of the universe.
Oh really? We have shown that for the kind of global overall
On Fri, Dec 15, 2000 at 05:20:35PM -0500, Deven T. Corzine wrote:
It's a pattern, not a program. Yes, it's straightforward to treat it as a
step-by-step procedure for matching that pattern, but by doing so, you lose
something of the gestalt of the whole.
You may deal in patterns, but
precedent is a always a justification not to change
anything. Of course, that argued against the wonderful regex extensions
that Perl 5 added, since they went against the way "it's always been"...
1) It is obviously faster to come to an answer earlier on in the
execution tha
Non-greedy matching is a very valuable Perl 5 regular expression feature
that simplifies many regular expressions. However, early on I discovered
what seems to be a failure of the mechanism -- matches were MORE greedy
than necessary. I'm not sure if other people noticed this, or just failed
Does anyone disagree with the premise, and believe that "d" is the
CORRECT match for the non-greedy regexp above?
Yes. The Camel's regex chapter reads:
You might say that eagerness holds priority over greed (or thrift).
For what it's worth, here's a quote from a Perl 5.005_03
Deven T. Corzine writes:
I haven't even SEEN an example where the current behavior is actually
preferable than my proposed behavior, have you? (And I'd expect at least a
FEW, though I suspect there are probably more counterexamples.)
I think the biggest problem with your idea is that it
On Thu, Dec 14, 2000 at 04:19:15PM -0700, Nathan Torkington wrote:
Deven T. Corzine writes:
I haven't even SEEN an example where the current behavior is actually
preferable than my proposed behavior, have you? (And I'd expect at least a
FEW, though I suspect there are probably more
d likewise *be* different.
I didn't need the long-winded explanation, and I don't need help with
understanding how that regexp matches what it does. I understand it
perfectly well already. I'm no neophyte with regular expressions, even if
Perl 5 does offer some regexp features I've never bothered
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven I'm not pushing for this to be fixed in Perl 5; it's been out
Deven there long enough, and there's no point worrying about it in
Deven that version. But that doesn't mean that the same design flaw
Deven should be kept in Pe
"Deven" == Deven T Corzine [EMAIL PROTECTED] writes:
Deven I haven't even SEEN an example where the current behavior is
Deven actually preferable than my proposed behavior, have you? (And
Deven I'd expect at least a FEW, though I suspect there are probably
Deven more counterexamples.)
If I
nded explanation, and I don't need help with
understanding how that regexp matches what it does. I understand it
perfectly well already. I'm no neophyte with regular expressions, even if
Perl 5 does offer some regexp features I've never bothered to exploit...
My point is that the current
This workaround DOES work, but it wouldn't be necessary in the first place
if the design of the regular expression didn't have this subtle flaw to
begin with. (And not all regexps will be so trivially patched up, either.)
I'm not pushing for this to be fixed in Perl 5; it's been out the
On Dec 14, Deven T. Corzine said:
You're asking for something like
/(?!b)(b.*?d)/
which is an "optimization" you'll have to incorporate on your own.
Thanks for the example. Unfortunately, your attempted workaround doesn't
even work for the example string; the "a" preceding "d"
ble than my proposed behavior, have you? (And I'd expect at least a
FEW, though I suspect there are probably more counterexamples.)
This is certainly a minor issue, but I believe the design is flawed in the
current Perl 5 implementation; why not fix the design properly for Perl 6?
Deven
($greedy) = /(b.*d)/; # "" (correct)
($non_greedy) = /(b.*?d)/; # "d" (should be "bd"!)
I'm sure this will complicate the NFA for the regexp, but it seems like
this really ought to be fixed, at least in Perl 6. (There's a good case t
On Dec 14, Randal L. Schwartz said:
Deven I haven't even SEEN an example where the current behavior is
Deven actually preferable than my proposed behavior, have you? (And
Deven I'd expect at least a FEW, though I suspect there are probably
Deven more counterexamples.)
If I want the leftmost B
Oh, my. I fear I may have ruffled some feathers here. I apologize; I was
hoping to spark a debate, not a flame war. Could we all please take a step
back and cool off for a bit, and not let this get personal?
I'm afraid it may seem like I'm ranting about Perl 5's regular expressions,
when I
"David L. Nicol" wrote:
Nathan Wiger wrote:
Well, this is not bad, only it's not without its problems. Say you
wanted to get your indices implicitly:
@a[getindices()];
@a[$r-get_x, $r-get_y];
@a["@{\(getindices())}"];
@a[join $",$r-get_x, $r-get_y];
Nathan Wiger wrote:
Well, this is not bad, only it's not without its problems. Say you
wanted to get your indices implicitly:
@a[getindices()];
@a[$r-get_x, $r-get_y];
@a["@{\(getindices())}"];
@a[join $",$r-get_x, $r-get_y];
Either of these could return an
"David L. Nicol" wrote:
Nathan Wiger wrote:
Well, this is not bad, only it's not without its problems. Say you
wanted to get your indices implicitly:
@a[getindices()];
@a[$r-get_x, $r-get_y];
@a["@{\(getindices())}"];
@a[join $",$r-get_x, $r-get_y];
Nathan Wiger wrote:
"David L. Nicol" wrote:
@a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
One problem that immediately jumps out at me is how to do this:
@a[[@x], [@y]];
That is, dynamically get your indices. The above seems ok when you know
them in
Jeremy Howard wrote:
That's true. I still think it's confusing to have such similar syntaxes mean
such different things. I'd also like to be able to say:
@a[[$i,$j,$k], [$x,$y,$z]]
to get two points.
Just in case anyone isn't aware of this:
using a "stuff'em into hash keys" N-dim
301 - 387 of 387 matches
Mail list logo
