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 mathematicians *do* say that.

> 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. *Everybody* has difficulties with
> regular expressions - about a quarter of my job is simply looking at
> other people's regex used in data transformations and deciding what
> small bug is causing them to fail given a certain input. 
> 
> There's simply no way to graphically show regexes now. Even use re
> 'debug' is terribly cryptic. The best way to deal with them right now
> is to burn a regex parser into your brain.

I believe ActiveState's IDE (if ActiveState has an IDE... in any case,
some IDE I've used) had a graphical regex debugger.  It was pretty cool.

[I'm snipping past some of your comments, even though they are good
points].

> now, luke, I'll start with your first principle --
> 
> "Because nobody's implemented it yet. [[ I'll refer to this later, let's call
>   it [Because]"
> 
> 
> And as *you* implied - building such a generator was easy.  

Yep.  I built one.  Thus my comment "There is a class of people whose
lives wouldn't be easier. Me, for one."  I build it, I maintain it. 

> (
>     ps - Regexp::Genexis the perfect example of why it should be a
>     'standard' module or operator.  (thanks for the pointer btw, Brad
>     ). Look at the limitations - no anchors, no lookahead, lookbehind,
>     code elements or conditionals.
> 
>     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.

Putting it in the core doesn't magically make it implemented, to which
you replied "of course" last time.  But apparently you don't understand.

I can tell you that it has a much better chance of making it in the core
if someone writes it first.  Hint.

We're an open source project.  The work has to come from somebody.  And
writing a module worthy of making it in the core distribution is quite a
bit more work than writing up a proof of concept module like I did.  It
also means that it has to be regularly maintained.

If you want to do that work, great.  Write the module, and say you'll
maintain it.  Then we'll talk about it going in the core.

Luke

Reply via email to