Thanks, but you forgot the important part about only retrieving the first 10 entries. I purposely included that to see how Arc would handle prematurely exiting an iteration.
Also, I think you may have forgotten to read the file. w/infile only opens the file, right?
I realize Arc doesn't have regex's yet, but some folks have been asserting that you can do just fine w/o them, so I was curious about an Arcy way to solve the parsing w/o regex's.
You're right. For the file's content, I just forgot to give it to the 'pmatch function (that's her file). For the test, well, that's quite trivial, provided you know there will be at least 10 values in your file (but, being given your code, that's the case anyway). Now let's consider pmatch only returns one value, then returns it (instead of a list of all values). As the file is a parameter, it is easy to know what's left to read.
(w/infile f "arcleaders.html"
(while (< count 10) (pmatch f "(\\d\\d?)\\..*?.+?<u>(.+?)<\\/u>.+?(\\d+)" action)))
I realize pmatch hasn't been written yet, but this seems odd. You're calling (pmatch f pat action) repeatedly, so where is the state info kept regarding the index of the last match, etc.? Your example reminds me of strtok in this regard, but I doubt that's what you had in mind.
With the Ruby example, the scan function invokes the supplied block repeatedly, but the break statement within the block will exit the scan function which is the desired behavior.
It's somewhat moot until someone writes pmatch though.
Well the f parameter has an index anyway, so the function knows what is left to be parsed anytime you call it, I guess ? Hmmm, I'll try to make a dumb version of pmatch and see what happens...
