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

Run Paint Run Run wrote:
>> I find this subject deeply fascinating. I think it would be cool if ruby had
>> more pattern matching built in, so that for instance, you could specify a
>> pattern in a block or method parameter list or the left side of an
>> assignment. Using unary star and parens, there's already some capability in
>> this direction, but it's fairly limited as a pattern matching language
>> compared to what Reg can do.
> 
> What are your thoughts on the applicability of these features to the
> stdlib? Are they generally useful? Is there a "killer app" that the
> core team may take notice of? :-)

Reg, Regexp, various parser tools are all declarative languages. A lot 
of data-processing type work can be done much more succinctly and 
expressively with a declarative language. With Regexp or other 
string-oriented tools, you're limited to data that comes as strings, but 
with something like Reg, that's not true; you can deal with data in 
arrays or hashes or whatever form it happens to be in. Not all tasks are 
naturally expressible this way, of course; I think it's nice to have the 
ability to switch between declarative and imperative coding styles. It 
is an abrupt paradigm shift, to see things declaratively. Not one that a 
lot of people are ready to make, at least right now.

> My approach was to determine what a minimally useful feature set would
> look like, so we'd have a starting point for discussion. Perhaps the
> lack of interest in this thread indicates that we've been
> unnecessarily abstract. :-/

I have my doubts as to whether a minimal feature set is all that useful. 
These seem to be complicated tools to create, and some pretty 
sophisticated features need to be in place (backtracking, 
backreferences, match-and-replace) before they're widely applicable. 
Perhaps you'll prove me wrong.

> On another note, regarding the Char class I suggested, I noticed that
> the ToDo file in the MRI repository has "objectify characters" as a
> suggestion. Is there still any interest in this aspect, at least?

If characters are to become some kind of distinct class, then I think 
they really ought to be made immediate values, with all the state stored 
in the actual reference, like Fixnum. The encoding as well as the code 
point would have to be packed in there, which makes it more difficult. 
If unicode were to live up to its promise to be a superset of all other 
character sets, that could make this easier.