Date:         Mon, 26 Feb 1996 01:15:48 GMT
Reply-To:     Chris Long <chris@OVIEW.DEMON.CO.UK>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Chris Long <chris@OVIEW.DEMON.CO.UK>
Organization: Oceanview Consultancy Ltd
Subject:      Re: Re[4]: TRUTH: You CAN'T USE a macro in the same DATASTEP

Well said, Ian.
 
Paul,  while I think that a lot of the code used in this argument is
complex and unlikely to reflect much of the mainstream use of SAS by
readers of this group, it is clear that the flat, sweeping 'TRUTHs'
you keep repeating are in fact (to use an Americanism) boloney.  You
have been (to use an Britishism) well and truly sussed.  Please don't
spread these untruths any further.
 
Chris.
 
--------------------------------------
 
In article <9601218249.AA824929560@westatpo.westat.com>, Ian Whitlock
<whitloi1@WESTATPO.WESTAT.COM> says:
>
>    I shortened the run-on PUT statement in Paul's latest version, turned
>    on SYMBOLGEN, MPRINT and MLOGIC, housed the code in a macro so that
>    MPRINT would report the code seen by the compiler, and added the new
>    6.11 feature - %PUT _USER_ ; - to see how this feature would report the
>    state of the macro variables during execution of the DATA step.
>
>    Observe the MPRINT of the shortened form of Paul's PUT statement.  It
>    doesn't contain any macro variable because the macro facility removed
>    the variable reference at compile time.  He placed the PUT after my
>    call to EXECUTE, hence it was executed after my %PUT, but without any
>    macro variable reference it was incapable of reporting the state of the
>    macro table when it executed.  A PUT statement is simply inadequate for
>    directly reporting the value of macro variable at execution time.  Note
>    that after the DATA step began executing SYMBOLGEN reports one and only
>    one execution time resolution of _BET which came from the %PUT housed
>    in a CALL EXECUTE.  Now let me remind you of Paul's statement of
>    February 7, 1996.
>
> >There is some evident confusion about when a macro assignment is resolved.
> >I will make a flat statement -
> >
> >I don't believe any result which shows a macro assignment resolved in the
> >same datastep as the assignment was made in.  Such demonstrations are
errors.
> >
> >This is one of the fundamental truths of SAS programming.  The datastep is
> >not executed until the run, so it cannot process the macro assignment.
>
>    These statements cannot be considered statements about SAS, but merely
>    statements about Paul's limited understanding of macro variable
>    assignment and resolution.  He has ably demonstrated with various
>    programs that he does not know how to resolve a macro variable other
>    than to enclose it in double quotes and write it in a PUT statement.
>
>    As for the challenge
>
> >Challenge:  If you can provide code which I can run which violates this,
> >I will buy you lunch at SUGI 21.  If you provide such code and it doesn't
> >work, you buy me lunch.  Code must be supplied over comp.soft-sys.sas
> >--
> >Paul Thompson, Ph.D.     |
> >Department of Psychiatry |
> >Case Western Reserve Univ|
> >Cleveland, OH  44106     |
>
>    I am unable to provide code that he can understand or even run without
>    changing, hence I will be glad to buy him a lunch within my limited
>    means and commensurate with the value of his knowledge of macro
>    resolution.
>
>    Ian Whitlock <whitloi1@westat.com>