>>Nadya,
>>
>>I've never found a problem with speed with the library. I'm not saying one doesn't exist, just that's it's not been my experience. Further, as I noted to Russell, this functionality will be in VFP 7.0 so, under the circumstances, there's no reason for me to change my recommendation. Thanks for the input, though.
>
>I've been testing this stuff in VFP 7. As of beta 1, the ALINES() solution is still an order of magnitude faster then the built-in word functions for large strings.
>
Tamar,

That may be true (for now at least), but it'd be pure speculation to say that this will remain the case.

Further, while it may be an order of magnitude faster, whether or not it's significant depends on the context. We all know that the FOR/ENDFOR iteration structure is faster than DO WHILE/ENDDO, but that doesn't mean that everytime we need to conditionally exit one we should use the FOR construct. Indeed, it would be a poor programming practice to do so.

As I stated before, the Words()/Wordnum() functions not only give this functionality, but more as well. Would you use ALINES(), for example, to extract every sentence of this paragraph? No! This would especially be true, if you already had a function that could do this that was already written, tested and proven.

This is not to say that ALINES() doesn't have it's place. However, from my presepctive (and since I already have a function that utilizes Words()/Wordnum()), I would restrict implementing ALINES() to those instances where performance was an issue. IOW, I see these instances as the exceptions. After all, why re-code, re-test, re-prove something that already exists?