String#to_rx ?

[Jeff Wood]

------=_Part_18797_23675044.1133097195053
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So in what way is String#escaped better than String#to_rx?

When I read #to_rx I can only guess at the specifics of the call ( somethin=
g
to do with regular expressions ... or perscriptions ) ... but what it's
doing to the string, no idea... when I read #escaped all the lights light
up ... ah, you want an escaped version of the string. There's a bit too
much implicit in #to_rx

And although from time to time I have been "thumbs-up" for adding

You obviously haven't read "Apocalypse 5" or "Synopsis 5". The whole
point of that syntax is to be able to clean up the regex syntax, i.e.,
to thin down the "punctuation soup". Did you know that many features of
Ruby have been heavily influenced by, and even lifted directly from,
Perl? The syntax for regular expressions, for example (with some minor
incompatibilities). So I don't really see where your "we shouldn't use
perlish stuff" argument is coming from; especially seeing as how the
suggestions in the mentioned articles intend to make Perl's regular
expressions less "perlish".

Nope, I haven't. And I surely don't plan to. And, I don't need a history
lesson from you, thanks anyways. I've been using ruby for a few years now
and am quite well aware of it's origins and some of the decisions that were
made early on ( as well as the features that were implemented to help Perl
users move away from Perl to Ruby ).

If you want Larry Walls "less perlish" perl ... by all means, perl6 should
be ready in about 5 years.

The only opinion that matters to me is Matz. If he likes it, I'm sure

How very individualistic of you.

Actually, it has NOTHING to do with individualism, even if I don't like the
choices, Matz is still the one that makes 'em. I have my opinions about
things, sometimes they match, sometimes they don't.

... If you'd like to continue this discussion, I suggest we move it off the
list, it's caused enough noise for everybody else.

j.

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood

------=_Part_18797_23675044.1133097195053--

 

[Stefan Lang]

When I read #to_rx I can only guess at the specifics of the call (
something to do with regular expressions ... or perscriptions ) ...
but what it's doing to the string, no idea... =C2=A0when I read #escaped
all the lights light up ... ah, you want an escaped version of the
string. ...

But escaped for what purpose? For usage as XML attribute value?
Or does it escape special shell characters? Or special regex
characters? Or special characters for File.fnmatch?

A string can be escaped for many purposes. I'm sure others can
come up with more examples. IMO adding a method to String is a
bad choice. Either new syntax, or use the existing Regexp.escape,
which is a clean and readable solution.

Regards,
Stefan

 

[Nikolai Weibull]

On 11/27/05, Nikolai Weibull

When I read #to_rx I can only guess at the specifics of the call (
something to do with regular expressions ... or perscriptions ) ...
but what it's doing to the string, no idea... when I read #escaped
all the lights light up ... ah, you want an escaped version of the
string. There's a bit too much implicit in #to_rx

As Stefan Lang already pointed out, that's totally non-sensical.

Nope, I haven't. And I surely don't plan to.

So why do you feel that you can comment on the syntax?

If you want Larry Walls "less perlish" perl ... by all means, perl6
should be ready in about 5 years.

The regular-expression syntax planned for Perl 6 has very little to do
with Perl 6 itself. I have no plans on waiting for or moving to Perl 6
once it is ready. That's also the reason why I really want the planned
syntax in Ruby, so that there wouldn't be a compelling reason to do so.

I'm not saying that "Apocalypse 5" is gospel, but there are some good
ideas in it, and I think that now that we have the chance (with the
imminent release of 2.0) we should review all parts of the language and
make sure that they're all up to code.

nikolai

 

[Jeff Wood]

------=_Part_20616_15407892.1133110348694
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I do agree that I should have reviewed the document before posting a
response. I have done that, and still hold to what I've stated.

The Perl syntax he proposed is a hideous mess of line noise ( no surprises
).

I don't believe that the suggested functionality can be added without
slowing regular expression matching.

But there IS one idea in the document I like and would require NO changes t=
o
regexp syntax.

# define a normal regex with 1 group
a =3D /(\d+)/

# add a rule for group 1s matching
a.rules << Rexexp::Rule.new( :group, 1 ) { |val| val > 20 }

# now play.
b =3D "200 19 14 21 1"
b.scan a
#=3D>[ "200","21" ]

... at least that's how I'd do it ... Beyond that, I still feel trying to
get anything more than "ideas" for features from Perl is NOT a good path fo=
r
ruby.

Anyways, I do see value in what you brought to the table ... but maybe next
time explain the feature for it's merits not "hey look what perl is doing!"
...

------=_Part_20616_15407892.1133110348694--

 

[Nikolai Weibull]

I do agree that I should have reviewed the document before posting a
response. I have done that, and still hold to what I've stated.

The Perl syntax he proposed is a hideous mess of line noise ( no
surprises).

So you think /(?:abc)/ is easier to read than /[abc]/? How about

I don't believe that the suggested functionality can be added without
slowing regular expression matching.

What functionality are you talking about? The obvious one that slows
down matching is the one that executes arbitrary Perl (Ruby) statments,
but you're certainly not forced to use that functionality if you don't
want to, which brings us to...

But there IS one idea in the document I like and would require NO
changes to regexp syntax.

# define a normal regex with 1 group
a = /(\d+)/

# add a rule for group 1s matching
a.rules << Rexexp::Rule.new( :group, 1 ) { |val| val > 20 }

# now play.
b = "200 19 14 21 1"
b.scan a
#=>[ "200","21" ]

... at least that's how I'd do it ... Beyond that, I still feel
trying to get anything more than "ideas" for features from Perl is NOT
a good path for ruby.

How is that easier to understand than

b = "200 19 14 21 1"
b.scan /(\d+){ |val| val > 2 }/
# => ["200", "21"]

? With this syntax, it's pretty obvious what's going on, at least I
think so. "Match a sequence of one or more digits and call the given
block to see if we should actually accept it as a valid match."

Furthermore, everything could be added _without_ changing the regex
syntax, but that's not the point. The point is to make the regex syntax
as expressive as possible, just like Ruby's syntax is as expressive as
possible (or at least tries to be).

Anyways, I do see value in what you brought to the table ... but maybe
next time explain the feature for it's merits not "hey look what perl
is doing!" ...

I didn't even mention Perl in my original posting. I mentioned an
article about a new regular expression syntax, which happened to be for
Perl 6, but I didn't say "Hey, look what almighty Larry Wall has said we
must do."

nikolai

 

[Jeff Wood]

------=_Part_26438_23641922.1133155540983
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

No further response. There isn't a point. I've stated my opinion, you've
stated yours. We aren't the only people in the world, and this is generatin=
g
far too much noise.

Let it be. You've brought it up, and I'm sure other people will chip in
with their $0.02USD

j.

I do agree that I should have reviewed the document before posting a
response. I have done that, and still hold to what I've stated.

The Perl syntax he proposed is a hideous mess of line noise ( no
surprises).

So you think /(?:abc)/ is easier to read than /[abc]/? How about
/\w+\s*=3D\s*\w+/ versus /<word> =3D <word>/w (or /<word><ws>=3D<ws><word=
/
without 'w' modifier and assuming word =3D /\w+/)?

I don't believe that the suggested functionality can be added without
slowing regular expression matching.

What functionality are you talking about? The obvious one that slows
down matching is the one that executes arbitrary Perl (Ruby) statments,
but you're certainly not forced to use that functionality if you don't
want to, which brings us to...

But there IS one idea in the document I like and would require NO
changes to regexp syntax.

# define a normal regex with 1 group
a =3D /(\d+)/

# add a rule for group 1s matching
a.rules << Rexexp::Rule.new( :group, 1 ) { |val| val > 20 }

# now play.
b =3D "200 19 14 21 1"
b.scan a
#=3D>[ "200","21" ]

... at least that's how I'd do it ... Beyond that, I still feel
trying to get anything more than "ideas" for features from Perl is NOT
a good path for ruby.

How is that easier to understand than

b =3D "200 19 14 21 1"
b.scan /(\d+){ |val| val > 2 }/
# =3D> ["200", "21"]

? With this syntax, it's pretty obvious what's going on, at least I
think so. "Match a sequence of one or more digits and call the given
block to see if we should actually accept it as a valid match."

Furthermore, everything could be added _without_ changing the regex
syntax, but that's not the point. The point is to make the regex syntax
as expressive as possible, just like Ruby's syntax is as expressive as
possible (or at least tries to be).

Anyways, I do see value in what you brought to the table ... but maybe
next time explain the feature for it's merits not "hey look what perl
is doing!" ...

I didn't even mention Perl in my original posting. I mentioned an
article about a new regular expression syntax, which happened to be for
Perl 6, but I didn't say "Hey, look what almighty Larry Wall has said we
must do."

nikolai

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood

------=_Part_26438_23641922.1133155540983--

 

[William James]

b = "200 19 14 21 1"
b.scan /(\d+){ |val| val > 2 }/
# => ["200", "21"]

irb(main):020:0> b.scan /(\d+){ |val| val > 2 }/
(irb):20: warning: regexp has invalid interval
(irb):20: warning: regexp has `}' without escape


irb(main):019:0> b.scan( /\d+/).select{|n| n.to_i > 20}
=> ["200", "21"]

 

[Trans]

So I'll put in the (likely) last 2 cents. I agree with Nikolai if that
there is a Regexp proper way to interpolate a string, that should be
used, and I'm all for anything that makes Regexp less cryptic and more
usable (the "perlishness" of Regexp is just the nature of them, that
won't change, but as Apocolypse shows it can be improved) Nonetheless,
that's all up to Matz and a furture version of Ruby and really no use
to us at the moment, so in that regard I have to agree with Jeff and
that's why I am making these methods a part of Facets:

String#to_re - Convert string to Regexp escaping.
String#to_rx - Convert string to Regexp non-escaping.
String#regesc - Regexp escape

T.

 

[Austin Ziegler]

The Perl syntax he proposed is a hideous mess of line noise ( no
surprises).

So you think /(?:abc)/ is easier to read than /[abc]/? How about
/\w+\s*=3D\s*\w+/ versus /<word> =3D <word>/w (or /<word><ws>=3D<ws><word=
/
without 'w' modifier and assuming word =3D /\w+/)?

No, but I don't think that they're regular expressions at that point.

I wouldn't be opposed to a parser-literal type being included in Ruby
if done right (because that's *really* what Larry proposed), but I
would be opposed to rewriting Ruby regex into the Perl6 format.

-austin

 

[Nikolai Weibull]

On 11/27/05, Nikolai Weibull

Jeff Wood wrote:

The Perl syntax he proposed is a hideous mess of line noise ( no
surprises).

So you think /(?:abc)/ is easier to read than /[abc]/? How about
/\w+\s*=\s*\w+/ versus /<word> = <word>/w (or
/<word><ws>=<ws><word>/ without 'w' modifier and assuming word =
/\w+/)?

No, but I don't think that they're regular expressions at that point.

No, but what we call regular expressions aren't in any way regular
either. Actually, it depends on how this is actually done. In Perl 6,
<word> will call the regex in the current grammar called 'word', so
that's certainly not regular. If <word> is simply substituted by
whatever 'word' is defined to in the current grammar, then that doesn't
change anything.

I wouldn't be opposed to a parser-literal type being included in Ruby
if done right (because that's *really* what Larry proposed),
Yes.

but I would be opposed to rewriting Ruby regex into the Perl6 format.

Why?

(In Perl 6 (vaporware, I know), the Perl 5 syntax will still be
available.)

nikolai

 

[Eric Mahurin]

So you think /(?:abc)/ is easier to read than /[abc]/? How about
/\w+\s*=3D\s*\w+/ versus /<word> =3D <word>/w (or
/<word><ws>=3D<ws><word>/ without 'w' modifier and assuming word =3D
/\w+/)?

No, but I don't think that they're regular expressions at that point.

No, but what we call regular expressions aren't in any way regular
either. Actually, it depends on how this is actually done. In Perl 6,
<word> will call the regex in the current grammar called 'word', so
that's certainly not regular. If <word> is simply substituted by
whatever 'word' is defined to in the current grammar, then that doesn't
change anything.

I don't think trying to push full parser capabilities into regex's is
the right way to go. Instead, I think we should have a standard OO
mechanism in ruby to build grammars - and easily put actions in. So,
in your example above, I think we should be able to do something like
this:

# we previously defined word, ws, and equal
assign =3D word + ws + equal + ws + word

This is exactly how my grammar package works. It is LL, but this same
way of defining grammars could be used LR/LALR parsing or
DFA/NFA/backtracking of regular expressions. Instead of specifing
your entire parser in a very complex string (the regular expression),
you simply create and combine grammars using methods to make your
parser (the most basic methods would be for creating an element,
sequencing (+), alternation (|), and recursion). You could easily
associate actions (i.e. ruby blocks) with certain elements with what
you are trying to parse. And since this is OO (and duck-typed), we
wouldn't be limited to just parsing characters like regex's - we could
parse tokens or whatever.

 

[Nikolai Weibull]

I don't think trying to push full parser capabilities into regex's is
the right way to go. Instead, I think we should have a standard OO
mechanism in ruby to build grammars - and easily put actions in. So,
in your example above, I think we should be able to do something like
this:

# we previously defined word, ws, and equal
assign = word + ws + equal + ws + word

That's a valid point.

Still, my original intent was to point out that the regex syntax may
benefit from an overhaul. Fine, forget about grammars and such, but as
an example for a possible improvement is that it should be just as easy
to embed a literal string as to embed another regex.

This is exactly how my grammar package works. It is LL, but this same
way of defining grammars could be used LR/LALR parsing or
DFA/NFA/backtracking of regular expressions. Instead of specifing
your entire parser in a very complex string (the regular expression),
you simply create and combine grammars using methods to make your
parser (the most basic methods would be for creating an element,
sequencing (+), alternation (|), and recursion). You could easily
associate actions (i.e. ruby blocks) with certain elements with what
you are trying to parse. And since this is OO (and duck-typed), we
wouldn't be limited to just parsing characters like regex's - we could
parse tokens or whatever.

Well, Perl 6 doesn't define the parser as a very complex string. It's a
set of regexes - a grammar. But I'm not saying that that's the best way
to do it. I like your grammar package and once namespaces are
implemented in Ruby I think that it can be made even sweeter (it's a
little too verbose at the moment).

nikolai

 

[Eric Mahurin]

Well, Perl 6 doesn't define the parser as a very complex string. It's a
set of regexes - a grammar.

Yep, your right. Even in perl5, you do it with a set of regexes -
where you can do regex recursion with (??{ $re }). This is one or two
more languages you have to learn on top of perl - the grammar/regex
language. And then trying to integrate actions into this becomes a
mess. I think my approach (no new grammar language - just classes,
objects, and methods) is a more flexible.

But I'm not saying that that's the best way
to do it. I like your grammar package and once namespaces are
implemented in Ruby I think that it can be made even sweeter (it's a
little too verbose at the moment).

Thanks. There are a few things I'm doing for my next release that
will help the verbosity:

- the recommended way to make a parser/lexer will be to sub-class
Grammar (you can do this in the current release - examples in the next
release will do it):

class Expression < Grammar
def initialize
# we don't have to use the Grammar:: prefix all over the place now
super(expr)
end
end
g =3D Expression.new
g.scan(...)

- make Grammar subclasses (in the package) effectively callable
(calling new). To do this, I just defined class and instance methods
with the same name as the classes that called klass.new. Before, you
would do something like this Grammar::Code.new {...}, and now (with
the above sub-classing Grammar for parsers), you'd say Code {...}. I
would have had real callable objects like Python, but this seems like
a good enough hack.