Thank you, Nick. I can indeed see situations where that would be an
improvement when dealing, as in my case, with repeat tokenizing while
the first set of numbered positional macros were still in play.
However, I am presuming that -macro shift- will not work with the
resultant macros. I've looked at your tknz as suggested and would
offer the following modification to handle my situation:
X=============================X
*! 2.0.2 NJC DCE Sept 2006
* 2.0.1 NJC 17 March 2006
* 2.0.0 NJC 12 June 2005
program tknz2
version 9
//
// stub() - optionally add a prefix to a positionally numbered macro
// parse() - character(s) upon which to parse per normal tokenize
// nochar - exclude parsing character from list
//
syntax anything(name=list everything id="list to parse required") ///
[, Stub(str) noCHAR Parse(str) ]
if "`parse'" == "" {
local parse " "
}
tokenize `list' , parse(`parse')
local i = 0
local j = 0
while "``++j''" != "" {
c_local `stub'`++i' `"``j''"'
if "`char'" == "nochar" & `"`parse'"' != " " {
local ++j
}
}
end
X=============================X
Note that I have made stub an option in the case that a user wanted to
keep it as a list of numbered positional macros. (This is potentially
dangerous, however, since the c_local makes them persist and they
could cause a problem with later looping through the list after a
further tokenize or the like. Perhaps it is *too* dangerous and stub
should be required, any thoughts?) The nochar option is new and would
cause the ado to skip the nonspace parse characters when creating the
new sequential macros. If folks think this is worth adding to SSC, I
will rewrite the hlp file with the added option. (I still think that
should be an option with -tokenize- !)
Thanks again to you both for your help in explaining this and
providing alternatives.
DCE
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
