My latest wacky idea for enhancing SL...

sounds like a great idea, voted

Voted- excellent idea

Being able to filter on "llGetOwner or anything owned by llGetOwner" would be nice, too..

i was actually wondering why these functions didn't already exist. at least the one to listen only to thing owned by the owner, including the owner the of course. but definitely listening only for messages that start with a key word would save a lot resources. currently scripts can only listen for exact words from either only one specific source, or from everyone. or have to listen for all messages from everyone or one source and filter out the ones it doesn't need.

Plz transfer yr votes to SVC-791, KTHX!

Voted and linked to SVC-790, which requests general regex parsing functionality for LSL as well.

How about

 listen(integer channel,string name,key id,string message) {
  	   if (llGetOwnerKey(id)!=llGetOwner())
  	   {
  			return;
  	   }
  	   else ... 

If id is an agent, llGetOwnerKey() returns that agent's uuid. It's what I use to make sure vehicles only listen to me or my hud, anyway.

Voted for 790 and 791.

Has anybody really done any back-of-envelope analysis of how much overhead doing regex parsing on chat messages would be?

I mean, if you had some significant number, say 100, of llListenRegex() listeners on a channel, with no other filtering, theoretically how much could it degrade sim-wide script performance?

I suppose someone could just run some tests with a fast regex vs a simple compare, using a variety of expressions from simple to complex. Without an idea of its impact, I would be inclined to avoid putting regular expressions as part of a Listen filter.

Though I think having regex functions available to LSL in general is a good idea. I'll vote for 790 for sure.

Yes, I have.

As I said in my comment, searching anchored regular expressions using a state machine is O(N) on the length of the string. You basically do a table lookup on each character in turn, until you hit a "no more matches" state.

If the RE engine is constrained (no subpatterns or backreferences) then the cost is going to be O(N)+O(M) where N is the length of the longest string and M is the number of targets matching the final pattern (which will have to be then filtered for distance, key, etc). The (M) factor is going to be the same whether llListen or llListenRE was used, so for this exercise it can be neglected.

If the same work is done with listeners with no filter on the string, that then use LSL, then the orders of magnitude of the cost are the same, but the constant is much higher, because you will have to trigger M listen() events and then perform the same comparisons as the original regular expression, except using mono or lsl2 code written by maybe 50 different mostly amateur programmers.

The only problem with that is that the initial setup for the DFA to get O(n) execution time is O(2^m) in terms of both time and memory, the latter of which could get fairly expensive, depending on the length of the pattern / expression.

If you simulate the NFA or use an implicitly-built state table, you get around the exponential construction cost, but the execution time becomes O(nm).

I don't know if that is a problem or not, but I think it goes without saying too much more that things like backreferences need to be left out of the regex pattern matcher for any llListenRE implementation.

Nice, this one is older and have more votes:

http://jira.secondlife.com/browse/SVC-791

Yes, I did mention that.
Yes, I suggested that, just in case it didn't go without saying.

The RE could even be restricted to glob-style patterns, simplifying the problem even more.
That's why I closed mine as a duplicate and asked people to transfer their votes there.

Regular expressions are used in all manner of applications. They are built-in to Mono's runtime libraries, for goodness' sake. It is laughably doubtful that the cost of using them would come anywhere near the cost of all the string and list manipulation people do in LSL to achieve the same results.

As for the difference between compiling a regular expression and executing, compiling usually occurs very rarely. If it were a serious concern, they could (worst-case) allow only static regular expressions, and have them parsed at compile time. Perhaps a simple new language type, like:

regex execPattern = re'^execute\s+([^\s]+)\s+in\s+([-+.0-9eE]+)\s*(sec|min|hour)$';
...
llREListen(..., execPattern, ...);
...
string input;
list matches = input*execPattern;
if (llGetListLength(matches) == 0)
{
   llOwnerSay("No match");
} else
{
   string wholeMatch = llList2String(matches, 0);
   string command = llList2String(matches, 1);
   float timeVal = (float)llList2String(matches, 2);
   string timeUnit = llList2String(matches, 3);
   ...
}

(Or whatever. I rather like that idea though; seems to me to fit the feel of LSL and it's sort of along the same lines as using multiplication with rotation variables for transformations. Maybe a strided list of begin/end indices would be better, but whatever....) Then the cost is all up-front. No run-time issues whatsoever. And it SHOULD still be sufficient for 99.5% of regular expression applications. (Of course, given that example you wouldn't be able to allow casting to a regex from a string--which I'd presume would cause compilation--but you could allow the opposite casting for debugging purposes.)

I really doubt such restrictions would be necessary, but if run-time performance is really THAT MUCH of a concern, there it is.