Date: Wed, 17 Feb 1999 12:09:50 -0700
Reply-To: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Subject: Re: Problem with constants
Content-Type: text/plain; charset=US-ASCII
Several of the messages I've received in response to my posting
lead me to think that I should have included a disclaimer saying
"I know what the problem is and how to fix it, but I think it's an
interesting error and thought I'd share it".
WHITLOI1 <WHITLOI1@WESTAT.COM> wrote:
>Jack Hamilton <JackHamilton@FIRSTHEALTH.COM> wrote in part.
>> A cow-orker came over with a program that was failing to run.
>> The log looked like this (greatly simplified):
>> 106 data _null_;
>> 107 put 'Top' carol
>> 108 'Left'alice
>> 109 'Right'ted
>> 110 'Bottom' bob;
>> 111 run;
>> ERROR 200-322: The symbol is not recognized.
>Jack, I don't think you should consider it a problem with the language.
It's not. If there were a published grammar for the SAS data step
language, the program above would probably not comply. If there's a
problem, it's that the compiler is being too lenient when it accepts
line 108. There's no way for it to know how to interpret line 109.
>so insensitive to separators shouldn't be writing programs. Do you know any
>computer lanuage which doesn't complain and produces desired results when you
>fail to separate tokens?
Many languages, including SAS, don't require a separator between tokens when
the tokens come from different character sets. "A=B*C;" is six unseparated
tokens. The problem in my example is that the use of the letter T is
ambiguous - it might be part of the current token , or it might start a
new one. The data step language is generally well-designed, and doesn't
have many ambiguities, but that's one.
A language with one-character variable names and a default operator
would meet your criteria. I guess it depends on how you define "token".
>He ended the message with
>> And, for my obscure code entry of the day,
>> data _null_;
>> input @ ('14FEB99'd-037cdx) char $1.;
>> put char=;
>> which might print "CHAR=4" (but then again, might not; you might get
>> the "SAS attempted to read past the end of a line" message, or you
>> might get an out-of-range message).
>You shouldn't see the error messages suggested, since the CARDS buffer
>is always padded.
If YEARCUTOFF=1800, you'll get the out of range message. If it's 2000,
you'll get the past end of line message.
>Now I will up the ante one notch with a more vicious
>form of the program.
> options yearcutoff=2000 ;
> data _null_;
> input @('14FEB99'd-037cdx)char$1;
> put char=;
Heh. Yes, that's a ferocious program. At least three red herrings.
West Sacramento, California