> > 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
> > 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
29 matches
Mail list logo
