> > 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
> > 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
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 exa
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, becaus
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 internationalizatio
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 => "
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
> >>>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 inverses of the
> >>>other.
> >>
> >>But they're not:
> >>
> >> " 3 foo" --> 3 --> "3"
> >
> >I'd say that tha
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 --
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 matc
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 C<3 but remainder(" foo")> ?
Would the remainder then be dropped when the numeric value changes?
I assume that replacing the valu
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 C<3 but remainder(" foo")> ?
Would the remainder then be dropped when the numeric value changes?
Juerd
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. *Ever
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 t
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 Luk
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
[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 ways
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
thing
> 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
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
> low-
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 tha
Edward Peschko writes:
> > > If you need to match the regex engine in reverse, in a totally unattached way
> > > via subroutine, then I would think the chance for subtle mistakes and errors
> > > would be exceedingly great.
> >
> > I don't understand how.
>
> it means that you have to reimpleme
Edward Peschko wrote:
yes, i see this is cool. I'd just hope that there would be an equivalent set of
rules that matches the entire regular expression engine, and distributed with
the 'standard' perl6 distribution if there is such a thing.. And that there isn't
too much of a performance hit in the
> > 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.
>
> Ye
> > 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 syn
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 ineff
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 o
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 routi
Edward Peschko writes:
> > 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, c
> 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 pa
Wh! :)
Childish? Who?
On Tue, 14 Sep 2004 23:22:08 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> 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
>
31 matches
Mail list logo
