Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MrC]

I'm wondering if anyone has explored the possibility of integrating PCREs into Rename, or expressions.

There are numerous expressions which are made cumbersome or impossible with the more limited existing language.  Likewise Rename rules.

Thoughts?

[rick.ca]

It would be a wonderful compliment/addition to the expression language and many different functions of the program. I suppose adding the library would be simple enough, but the real challenge would be incorporating it in a friendly way in all the different places it might be applicable.

[MrC]

It would be a wonderful compliment/addition to the expression language and many different functions of the program. I suppose adding the library would be simple enough, but the real challenge would be incorporating it in a friendly way in all the different places it might be applicable.

Agreed, nice to have.

How about a new function called PCRE(^expression^).  This works in Rename, expressions.  That's a good start.  The special meaning of "/" and "\" might have to be escaped for parameters within the PCRE function parameter list.

It would simplify many expressions, even obsoleting or generalizing some (ignoring any performance potential issues).

[rick.ca]

How about a new function called PCRE(^expression^).

Yes, I figured it would have to be a self-contained expression, rather than incorporated directly in the expression language. But I suppose it could have it's own escape character. Either way, I'm not sure how it should handle returning multiple variables...

It doesn't matter, but I think Regex() would be a more meaningful name for most people.

[marko]

It doesn't matter, but I think Regex() would be a more meaningful name for most people.

Saved me a google search there rick, cheers

I've never had any dealings with "Regular Expressions", is it a hard language to grasp?

-marko

[rick.ca]

I've never had any dealings with "Regular Expressions", is it a hard language to grasp?

With your grasp of the expression language and other such things, I imagine you would consider it rather simple. I have little aptitude for anything to do with programming, so I'm not one to suggest it's easy. A normal first-time reaction to regex is that its very cryptic and best avoided unless absolutely necessary. But it has a very limited scope (i.e., it's just about recognizing patterns in strings for the purpose of extracting sub-strings) and is very logical, so it's not that bad. This Regular Expression Tutorial is pretty good—whether you want to learn it, or just get a quick overview.

[MrC]

There's a HUGE difference between PCRE and other, older forms of regular expressions (basic, extended, posix), with the latter having significant limitations.  I chose to use PCRE in my request here, because it is the correct choice should integrating a regular expression language become a possibility.  Let's not muddy the waters yet with implementation details.

Regular expressions can be trivial or quit complex, depending upon the situation and needs.  But it would be a mistake to caution or worry that "it has a very limited scope".  They are a powerful *generalized* solution that obsolete many of today's MC functions (RemoveRight/Left, Left, Mid, etc).  These are the "very limited scope" solutions.   Unless you understand finite automata and language theory, its best not to comment on RE's strengths and weaknesses.  They solve an extraordinary number of problems, with simplicity and generality, that users here face routinely.

Marko - with today's expressions, for example, how would one remove all characters up to the first space in a text?  Or strip an arbitrary number of certain pronouns or determiners or a sequence of known or arbitrary number of characters?  Regular expressions make this kind of stuff trivial and easier to read.  Many of today's expressions shared by users are obscenely long and and needlessly complex.

Or lowercase all prepositions not handled already by MC?  This is it (just a few prepositions below):

s/\b(up|on|in|under|through)\b/\1/

Anyway, I hope folks see the power of these and show their interest.
More info: http://en.wikipedia.org/wiki/Regular_expression

[rick.ca]

But it would be a mistake to caution or worry that "it has a very limited scope".

I think it was clear I was not referring to mistake or caution. "Recognizing patterns in strings for the purpose of extracting sub-strings" may not be a perfect description of it's scope. But if there's practical application outside of this, I wish you would explain what that is.

It might be important to be more specific about how and where it might be used in MC, or the conclusion could be it's not really necessary (MC already provides the most common functions it might be used for) and/or would be too complex for the average user to make practical use of.

For example, the existing search function would be far more powerful if regex could be used. But how is that to be implemented? Someone comfortable with regex would expect to be able to enter an expression directly in the search box. Is that going to create a problem for those who don't understand it? I'm not sure. Maybe it should be restricted to the search dialog—but the same consideration is applicable there. It's even more complex because there are so many things that could be handled with the existing expression language or regex or a combination of the two. Restricting it to it's own expression language function would limit it's application. Incorporating it fully into the existing expression language might be too complex—for both it's implementation and the results.

[MrC]

Rick, I'm sorry, I don't know where your discussion is going.  I asked if others see how there is tremendous value / utility of PCRE, and the discussion is turning into "Yeah, but its hard", "Yeah, but they are limited", "Yeah, but have you thought of everything?", "Yeah, but they don't slice bread".

Really, lets bring the discussion back to focusing on how this might move forward, instead of dumping a list of barriers which halt advancement.

[rick.ca]

Please re-read what I said and then clarified. I was asked if it was "hard." I said, in effect, in the context of it's scope, no. In other words, it's not something that would replace the existing expression language or shine your shoes. It's certain not something that's complex because of it's breadth of scope. On the other hand, I could also say it's complex because of it's inherent simplicity and mathematical elegance. That doesn't mean it's bad or hard or that this constitutes a barrier of any kind.

[MrC]

I know this is likely to not happen, but I'll hope anyway.

In this thread, I really wanted to give an answer such as:

([album],[comment],[year]) = /^(.+) \((.+), (\d{4})\)$/

With a single expression entry area for tag editing, and PCRE and perl-style list assignment, all 3 fields could have been parsed, and assigned in one shot.  This obviates the need to work out programming solutions using functions such as Right(), ListItem(), etc., providing a more generalized string manipulation toolkit.

Here's to wishes...