[#24648] [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <redmine@...>

Bug #1852: Enumerable's #hash Raises ArgumentError When Recursive Values are Present

20 messages 2009/08/01
[#24649] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/01

In article <[email protected]>,

[#24652] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <runrun@...> 2009/08/01

> Is it valuable to implement such function?

[#24673] [Feature #1857] install *.h and *.inc — Roger Pack <redmine@...>

Feature #1857: install *.h and *.inc

21 messages 2009/08/01

[#24732] [Bug #1873] MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group — Run Paint Run Run <redmine@...>

Bug #1873: MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group

12 messages 2009/08/03

[#24775] [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties — Run Paint Run Run <redmine@...>

Feature #1889: Teach Onigurma Unicode 5.0 Character Properties

30 messages 2009/08/05

[#24786] [Bug #1893] Recursive Enumerable#join is surprising — Jeremy Kemper <redmine@...>

Bug #1893: Recursive Enumerable#join is surprising

24 messages 2009/08/06
[#28422] [Bug #1893] Recursive Enumerable#join is surprising — Yusuke Endoh <redmine@...> 2010/03/02

Issue #1893 has been updated by Yusuke Endoh.

[#28438] Re: [Bug #1893] Recursive Enumerable#join is surprising — Yukihiro Matsumoto <matz@...> 2010/03/03

Hi,

[#24854] embedding ruby 1.9 frustration — Rolando Abarca <funkaster@...>

Hello,

12 messages 2009/08/10

[#24982] [Feature #1961] Kernel#__dir__ — Yutaka HARA <redmine@...>

Feature #1961: Kernel#__dir__

26 messages 2009/08/19
[#28898] [Feature #1961] Kernel#__dir__ — Roger Pack <redmine@...> 2010/03/23

Issue #1961 has been updated by Roger Pack.

[#25025] [Backport #1975] Backport Dir.mktmpdir — Kirk Haines <redmine@...>

Backport #1975: Backport Dir.mktmpdir

12 messages 2009/08/21

[#25041] Proposal: Simpler block format — Yehuda Katz <wycats@...>

I'd like to propose that we add the following syntax for procs in Ruby:

45 messages 2009/08/23
[#25046] Re: Proposal: Simpler block format — Caleb Clausen <caleb@...> 2009/08/23

Yehuda Katz wrote:

[#25049] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <[email protected]>wrote:

[#25058] Re: Proposal: Simpler block format — Yukihiro Matsumoto <matz@...> 2009/08/23

Hi,

[#25059] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <[email protected]>wrote:

[#25063] Re: Proposal: Simpler block format — "David A. Black" <dblack@...> 2009/08/23

Hi --

[#25068] Re: Proposal: Simpler block format — brian ford <brixen@...> 2009/08/24

Hi,

[#25086] [Bug #1991] ruby should use twolevel namespace on OS X — Michal Suchanek <redmine@...>

Bug #1991: ruby should use twolevel namespace on OS X

12 messages 2009/08/24

[#25208] Module#prepend and Array#prepend — Yehuda Katz <wycats@...>

Matz,

23 messages 2009/08/30

[#25210] [Feature #2022] Patch for ruby-1.8.6 and openssl-1.0 — Jeroen van Meeuwen <redmine@...>

Feature #2022: Patch for ruby-1.8.6 and openssl-1.0

15 messages 2009/08/30

[#25220] [Bug #2026] String encodings are not supported by most of IO on Linux — Vit Ondruch <redmine@...>

Bug #2026: String encodings are not supported by most of IO on Linux

18 messages 2009/08/31

[ruby-core:25181] RegOOps: An Object-Oriented Approach to Pattern Matching

From: Run Paint Run Run <runrun@...>
Date: 2009-08-29 17:41:41 UTC
List: ruby-core #25181
Regexps in Ruby can feel like a jagged edge to the otherwise smooth
curves. For all the syntactical smarts we employ so as to avoid
Perl-like punctuation, regular expressions take us two steps back,
their readability deteriorating with their length. They pry us from
Ruby's embrace, requiring proficiency in a new language, bereft of
familiar idioms. Regexps are neither introspective, w.r.t the pattern
itself, nor extensible with inheritance, mixins, or new method
definitions. Put another way, they don't act like we expect objects to
act.

For some tasks, regexps are certainly the superior tool. When you
require lookahead, nested constructs, and other advanced features,
their worth is evident. However, most regular expressions are nowhere
near as complicated. They may be used to determine whether a String
contains a number, or to extract a YYYY/MM/DD-format date. So, I'm
wondering whether we can make the common case easier by creating a
Regexp-lite that follows Ruby semantics and style without the
unnecessary complexity/punctuation? Traditional regexps would, of
course, still be available for complex tasks.

Imagine a String as an Array of Char objects. The Char class would
define predicate methods corresponding to Unicode and regexp
properties. For instance Char#lowercase? or Char#digit?. The
implementation is trivial because Regexps are used internally.

Matching the String against a pattern is now a case of calling the
appropriate predicate methods on the underlying characters. For
example, match(/\w+/) could be expressed as match(:word). This would
succeed if at least one character in the string returns true for
Char#word?. Similarly, match(:hex, :blank, :digit) would:

* Call #hex? on each character until it succeeds then set a flag to
signify that the match has began.
* Once #hex? has returned true once, try calling #blank? for every
subsequent character.
  * If it matches, #blank? becomes the current predicate;
  * Otherwise #hex? remains the current predicate.
* Once #blank? is the current predicate, try calling #digit? for every
subsequent character
  * If it matches, then the match has succeeded so we can stop.
  * If it doesn't match, continue calling #blank? on each character
until its neighbor matches #digit?

IOW, it matches non-greedily, assuming each term should match as many
times as it can while still allowing the overall match to succeed. My
current mockup doesn't try backtracking, but it certainly could. I'm
using String#ematch to add implicit start/end anchors.

So even at this point we have a more Rubyish interface, with no line
noise, which can be extended by modifying the Char class.

Each term has an implicit capturing parentheses around it, and #match
will return MatchData[1] so numbered captures will work.

Wildcards can be supported with a Char#any? predicate that always returns true.

Even if you stop here, you have a reasonably capable Regexp subset. If
additional functionality is desired, we can support non-Symbol terms.
A Fixnum term could represent a back-reference. A Range argument could
represent a character class, e.g. match(:digit, 5..9) =>
match(/\d+[5-9]+/). A String could represent a literal String, e.g.
match('glark') => /glark/. An Array could be used for alternation such
that one of its elements are required to match. A Hash could be used
to support named captures such that {:name => :digit} matches a digit
and captures them to the :name group. And so on. The overarching
benefit is that patterns feel like Ruby.

I've so far talked in terms of matching against Strings, but the
generality of this approach suggests that it could be associated with
any enumerator. (I've overloaded String#chars to return Char objects
for String). This could allow functional-style matching against data
structures.

There are clearly a lot of unanswered questions to consider. Is there
any interest in a core implementation along these lines, or is the
status quo seen as ideal? :-)

In This Thread

Prev Next