No, that first route is unnecessary. How about
program foo
gettoken data 0 : 0, parse(",")
syntax [, * ]
use `data', clear
count
...
end
That way, any -if- or -in- are just bundled within `data'.
Nick
[email protected]
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Nick Cox
> Sent: 26 November 2004 16:19
> To: [email protected]
> Subject: st: RE: RE: RE: Parsing not-quite-standard syntax
>
>
> That's much clearer to me now. You've discovered that
> -if- and -in- are checked for consistency with the
> data in memory. There seem to be two routes to follow.
>
> -gettoken- can look for -if- and pick up what follows.
> But that could be several tokens e.g.
>
> if foo > 20 & bar < 10
>
> so you have to keep going until you find an -in-
> or a comma. And vice versa.
>
> You read it your dataset and then process the
> other stuff. Say
>
> gettoken data 0 : 0
> use `data', clear
> syntax [if] [in] [, * ]
> marksample `touse'
> keep if `touse'
> ...
>
> Nick
> [email protected]
>
> David Harrison
> >
> > You say 'Stata isn't good at extra-sensory perception'
> > however the command -use- can manage it...
> >
> > . clear
> >
> > . use auto.dta if foreign==1
> > (1978 Automobile Data)
> >
> > . tab foreign
> >
> > Car type | Freq. Percent Cum.
> > ------------+-----------------------------------
> > Foreign | 22 100.00 100.00
> > ------------+-----------------------------------
> > Total | 22 100.00
> >
> > . clear
> >
> > . use auto.dta in 1/10
> > (1978 Automobile Data)
> >
> > . count
> > 10
> >
> > The syntax looks standard, but cannot be parsed by the
> > -syntax- command. Suppose the program I wanted to write was
> > as follows (in reality it is more complex, obviously)...
> >
> > program foo
> > syntax [name] [if] [in] [, *]
> > use `namelist'.dta `if' `in' , `options'
> > end
> >
> > Then...
> >
> > . clear
> >
> > . foo auto if foreign==1
> > foreign not found
> > r(111);
> >
> > . foo auto in 1/10
> > Obs. nos. out of range
> > r(198);
> >
> > So what I am trying to work out is how to manually parse the
> > input (using -gettoken- and the like) to identify the name
> > (if there is one), if statement (if there is one), in
> > statement (if there is one) and options (if any are specified).
> >
> > I could get around it by putting the [if] and [in] as options
> > instead, eg
> >
> > syntax [name] [, ifopt(string) inopt(string) *]
> >
> > but this goes against the appeal of the intuitive standard
> > syntax of Stata, so I wondered if anyone had overcome this
> > problem before?
> >
> > David
> > [email protected]
> >
> > Nick Cox
> >
> > > I don't however understand the bit about
> > > variables not in memory. Stata isn't good
> > > at extra-sensory perception...
> > >
> > > David Harrison
> > >
> > > > I want to write a command with the syntax
> > > >
> > > > command [name] [if exp] [in range] [, opt1 opt2 *]
> > > >
> > > > BUT, the -if exp- and -in range- are to be applied in a -use-
> > > > statement, so they may involve variables that are not in the
> > > > dataset in memory. Any suggestions on how I can parse this to
> > > > get the locals `namelist' `if' `in' `opt1' `opt2' and
> > > > `options' that would be produced by -syntax-?
>
> *
> * 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/
>
*
* 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/
