Focus on IT Recommend

Home > redis - Should "glob" style patterns be left as STRING! or is there a smarter way?

redis - Should "glob" style patterns be left as STRING! or is there a smarter way?



I'm tinkering with an interface to Redis pub/sub that can do patterns like:

 PSUBSCRIBE news.jazz.figurative

Despite the absence of delimiters, Redis accepts these as strings (implicit by spaces). Of course in Rebol, these would be WORD! tokens.

First thought in mapping the ideas was that it would be cool to use a PATH! since they have structure and can be built and introspected programmatically (count how many elements in the path, take the last one off, etc.) with no searching for dots. It's also no more characters:

 PSUBSCRIBE news/jazz/figurative

The last one is the trick, though. Although you can build a single-element PATH! in a programmatic fashion (e.g. from BLOCK! like to-path [n*]), the default tokenizer would classify that last one to be a WORD! when you enter it directly. So you'd have to make PSUBSCRIBE accept a parameter of either [word! path!]

PSUBSCRIBE: func ['pattern [word! path!]] [
    pattern: to-path pattern
    print [{The pattern you passed in was} mold pattern]

    insert pattern 'alt
    print [{Inserting at head of path yields} mold pattern]

    print [{The number of path elements is now} length? pattern]

In a sense it "works":

>> psubscribe news/*
The pattern you passed in was news/*
Inserting at head of path yields alt/news/*
The number of path elements is now 3

...but notice that I had to make pattern a quoted parameter (['pattern]). If you wanted to pass a pattern which was stored in a variable, the quoting means it would think the name of the variable is the actual pattern:

>> mypattern: 'news.*

>> PSUBSCRIBE mypattern
The pattern you passed in was mypattern
Inserting at head of path yields alt/mypattern
The number of path elements is now 2

Basically, my idea wouldn't have been a bad one if I were creating a REDIS dialect. Which I might take a shot at. But right now I'm trying to get these things working inside of the DO dialect, and I can't change the evaluator's rules to give paths new behavior without quoting them.

So that's the part I know but am just documenting. :) Now the question: if I'm stuck with the DO dialect, do I just use STRING! as a cop-out? Calls would have to involve either of the two kinds of string delimiters:

 PSUBSCRIBE "news.jazz.figurative"
 PSUBSCRIBE {news.*}

Then again, there is BLOCK!

 PSUBSCRIBE [news jazz figurative]
 PSUBSCRIBE [news *]

This gives a structural layer so that it's broken into parts and one doesn't have to parse out the dots. Yet the stars seem to be able to happen anywhere, not just in a slot in the hierarchy.

Maybe I'm trying to put structure on something that's really just a string and can't reasonably be modeled as anything else. Is that the case? If so I'm linking to this question in the source as justification for the decision. :)

redis glob rebol dialect
  this question
asked Oct 20 '12 at 1:32 HostileFork 21.5k 6 56 109


1 Answers


You can pass a reference through a literal parameter:

mypattern: 'news/*
PSUBSCRIBE :mypattern

On the modeling question, are your tokens always compatible with REBOL's word composition rules? Also, there is no way to check if a star is present without forming the word, so perhaps it should be strings in the first place. And stars do have meaning within strings when used with find/any.

  this answer
edited Oct 22 '12 at 16:25 answered Oct 22 '12 at 16:15 rgchris 2,134 10 17      The path! type is a tantalising, yet frustrating beast. I use them in QM for link shorthand all the time, but without the paren! syntax, they'd be useless: link-to articles/(article/title) –  rgchris Oct 22 '12 at 16:20      As mentioned in chat, I just went with STRING!. Another technical reason is that using WORD! entities to "bind" to arbitrary string-named things that exist outside the Rebol space--even if they fit within what a legal "word" could be--is probably an unsound practice. –  HostileFork Nov 8 '12 at 16:37



------splitte line----------------------------