If the generator was used as the primary way to testing the regex
engine, do you really think that any of these limitations would
exist?
Sigh. [Because] seems to have flown right by you.
Ok, I think this thing has pretty much played itself out, but I hate ending
on a
On Thu, 23 Sep 2004, Luke Palmer wrote:
Edward Peschko writes:
I'd say that that's a caveat of implementation, sort of a side effect
of handling an error condition. By your criteria there are very few
inverses - you could say that multiplication isn't an inverse of
division because of zero, for
If the generator was used as the primary way to testing the regex
engine, do you really think that any of these limitations would
exist?
Sigh. [Because] seems to have flown right by you.
Ok, I think this thing has pretty much played itself out, but I hate ending
on a
On Fri, Sep 24, 2004 at 10:24:32PM -0400, Aaron Sherman wrote:
On Fri, 2004-09-24 at 16:58, Edward Peschko wrote:
Ok, ok, I'll give you that point ... lets call them 'intimately related' and
leave it at that... if you say 3 foo and your algorithm goes:
3 foo = 3 = 2
then you
On Fri, 24 Sep 2004 19:46:37 -0700, Edward Peschko [EMAIL PROTECTED] wrote:
You could even say that in the chinese case that if you have
?$B#3 -- 3 -- 3
that's a bug. It had *better* turn back into ?$B#3 when you do
the int to string conversion. That's a internationalization snafu
if you
Edward Peschko writes:
I'd say that that's a caveat of implementation, sort of a side effect
of handling an error condition. By your criteria there are very few
inverses - you could say that multiplication isn't an inverse of
division because of zero, for example.
Err, that's funny, because
From: Edward Peschko [EMAIL PROTECTED]
To: Jeff Clites [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Bcc:
Subject: Re: S5 updated
Message-ID: [EMAIL PROTECTED]
Reply-To:
In-Reply-To: [EMAIL PROTECTED]
ok,
I'm going to answer both you and Luke in the same message to save time.
I'm
Jeff Clites wrote:
On Sep 23, 2004, at 5:27 PM, Edward Peschko wrote:
On Thu, Sep 23, 2004 at 08:15:08AM -0700, Jeff Clites wrote:
just like the transformation of a string into a number, and from a
number to a string. Two algorithmically different things as well,
Edward Peschko wrote:
Well, there re two responses to the that's not a common thing to want to do:
1) its not a common thing to want to do because its not a useful thing to do.
2) its not a common thing to want to do because its too damn difficult to do.
I'd say that #2 is what holds.
Austin Hastings skribis 2004-09-24 12:05 (-0400):
Actually, that raises a good point: Should 3 foo convert to number 3,
or should it convert to C3 but remainder( foo) ?
Would the remainder then be dropped when the numeric value changes?
Juerd
Juerd wrote:
Austin Hastings skribis 2004-09-24 12:05 (-0400):
Actually, that raises a good point: Should 3 foo convert to number 3,
or should it convert to C3 but remainder( foo) ?
Would the remainder then be dropped when the numeric value changes?
I assume that replacing the value
On Fri, Sep 24, 2004 at 11:36:43AM -0500, Rod Adams wrote:
Output would be a step by step graph of the internal logic used to match
/ not match the string. I'd break the RE up into the same pieces the
Engine does, then show how that subrule matched char a, then char b, but
failed to match
Rod Adams writes:
Edward Peschko wrote:
Running a regular expression in reverse has IMO the best potential
for making regexes transparent - you graphically see how they work
and what they match.
I have to disagree here.
For what it's worth, I agree with your disagreement -- and you
On Fri, 2004-09-24 at 16:58, Edward Peschko wrote:
Ok, ok, I'll give you that point ... lets call them 'intimately related' and
leave it at that... if you say 3 foo and your algorithm goes:
3 foo = 3 = 2
then you know something is desperately wrong.
Yes, and you know that because
How do you do that? Generation and matching are two different things
algorithmically.
yes, but they are intimately linked. just like the transformation of a string
into a number, and from a number to a string. Two algorithmically different
things as well, but they'd damn-well better be exact
On Sep 22, 2004, at 5:06 PM, Edward Peschko wrote:
How do you do that? Generation and matching are two different things
algorithmically.
yes, but they are intimately linked. just like the transformation of a
string
into a number, and from a number to a string. Two algorithmically
different
[EMAIL PROTECTED] wrote:
I'll show you. Here are some of the generators. This is very dense,
functional code. Read at your own risk (but I'm certainly not writing
it to be executed!).
Quite. ;)
For the regexp /a aa aaa a aa/, this would sequentially
search through all possible
On Sep 23, 2004, at 5:27 PM, Edward Peschko wrote:
On Thu, Sep 23, 2004 at 08:15:08AM -0700, Jeff Clites wrote:
just like the transformation of a string into a number, and from a
number to a string. Two algorithmically different things as well,
but they'd damn-well better
ok, cool, I'm beginning to understand perl6 patterns a bit better.
Just a tiny request though (and I seem to remember this being
discussed)
You were the one who initiated the thread :-)
Ah yes, I forgot about that. Damn brain cells.. ;-)
- I wish that there was an easy syntax to
The reason for the modifier (or even a new operator (g/ for example) is that
you can easily test your regular expressions. The interface is trivial - all you
have
to do is switch your m/ out for g/, and sit back and see how your patterns
translate
into strings.
Yeah, that looks
On Wed, 2004-09-22 at 10:49, Luke Palmer wrote:
Let me come right round to my point about perl being open source.
Someone has to do the work somewhere, and making it standard or core
doesn't change that. It just means that it'll take longer.
It also means that there's a possibility that the
First off, I'll point out that this belongs on p6l and nowhere else.
Edward Peschko writes:
It all comes down to what you think is a 'low level' op.. Some
languages think that regular expressions themselves aren't low level
enough to be included in the language, perl thinks that it is
I've been working at updating the various synopses on dev.perl.org.
In particular, you folks might like to know that the regex synopsis at:
http://dev.perl.org/perl6/synopsis/S05.html
is no longer two years out of date :-)
Larry
ok, cool, I'm beginning to understand perl6 patterns
On Tue, 2004-09-21 at 02:52 -0600, Luke Palmer wrote:
If you replace the first line:
method Rule::Group::generate(Int $n) {
With
multi generate (Rule::Group $group: Int $n) {
Everything ought still to work.
I think the best you can do is to implement it as a routine. You
Edward Peschko writes:
Ok, fair enough.. although I'm not sure that I'm all that sure I'm completely
happy-with/understand the syntax described in that article. It works for the trivial
cases, but what about complex grammars?
It works for anything. It gets pretty inefficient in the case of
Luke Palmer wrote:
Edward Peschko writes:
Ok, fair enough.. although I'm not sure that I'm all that sure I'm completely
happy-with/understand the syntax described in that article. It works for the trivial
cases, but what about complex grammars?
It works for anything. It gets pretty
26 matches
Mail list logo
