|
Peter,
thanks for your thorough thoughts and once again I'm embarassed by
how much my limited command of the english language limits my line
of argumentation. (I know, I know, many of you have told me that
my english is quite good ... so I'd probably better say: lucky you
are that my english prevents me from posting more ;-) )
I'm honestly surprised. In my opinion being able to insert at any
point in a datastep a sequence of statements like
target = gettarget('INPUT');
infile ksds key=...;
input ... ;
rc = settarget('INPUT',target);
input ... ;
is not at a matter of 'high sophistication'.
Having the choice between ...
a) a technique which is supported by the bare bone's language
... and ...
b) having to rely on programming standards or as I would put it
"having to depend on other's adherence to programming
standards"
... I'll clearly favour the independent and technically robust
solution.
But somehow I get the impression: that's just me. ;-)
Kind regards
Robert
> -----Ursprüngliche Nachricht-----
> Von: SAS(r) Discussion
> [mailto:SAS-L@LISTSERV.UGA.EDU]Im Auftrag von
> Peter C
> Gesendet: Sonntag, 29. April 2007 14:30
> An: SAS-L@LISTSERV.UGA.EDU
> Betreff: Re: Checking if macro exists? (Was Re: Macro Quoting)
>
>
> as declared:
> On Sat, 28 Apr 2007 10:25:07 +0200, Robert Bardos
> <bardos2@ANSYS.CH> wrote:
> ><quoting Chang Chung>
> >I just thought that it would be nice to have
> >a function that let's us know what sas knows here.
> ></quote>
> >
> >Agree wholeheartedly. We all (well, some of us) came
> to value ......
>
> more agreement from me here (well, almost)
>
> I too, wish to avoid contention with the existing
> environment, for
> example: when I put my (mini-application-extension)
> formats into the
> formats search path; or I put my
> (mini-application-extension) macros into
> the sasautos option value.
> These wishes are both solved by macro %addoptn() which
> can be seen at
> http://support.sas.com Sample 305.
> That macro adds to the environment rather than replacing it.
> I expected also to create a macro to "balance"
> %addoptn() which would be
> %remove_feature()
> It seemed appropriate at first, that:
> when I insert, I should remember to remove afterwards.
>
> In SAS9, from sashelp.vformats, I can see formats
> available in the current
> environment. When my mini-app-extension needs to create
> its own formats,
> it can create the next NN in formats named like
> $mAppNNf. If we need only
> avoid conflicts with macros already compiled, my
> mini-app-extension could
> do something similar with the names of macros or
> automatic macro variables
> that it needs to create.
>
> However, both options -fmtsearch and -sasautos, are
> associated with puting
> things like formats and compiled macros into the global
> environment of the
> session that *cannot* be removed!
>
> OK, macros and formats can be replaced - but the name
> cannot be removed
> from the global session environment.
> Especially notice that SAS/AF applications do not
> replace a format when it
> is recompiled. The AF application needs to be restarted
> for a recompiled
> format to have any effect.
>
> So, there is (probably) no way to reinstate to the
> environment as it was
> before formats or macros have been compiled!
>
>
> Also, as Ian Whitlock points out, although we can query
> the current
> environment, that won't tell us about what will happen *next*.
> And that may be even more important for the
> business-like purpose of the
> application.
>
>
> I've stopped worrying -
> - I think no one needs this level of sophistication
> .......
> ............
> unless you know different ............. ?
>
>
> I've also stopped expecting the environment to tell
> "me" what I should
> know, or could be told by the calling routine.
> For example,
> 1
> in a data step, the names of data sets being created
> are (nearly) always
> known when the code is written, so why seek a feature
> in the platform to
> expose that information as automatic macro variables,
> or through some new
> macro ??
>
> 2
> if knowing the name of the caller's environment
> (macro name or include-
> progrqam name) is important, then write the simple code
> to pass the
> information to sub-routines
> (e.g.macros/included-code/title/footnote).
>
> Do not make the called routines or language more
> complicated to expose or
> discover information that is known to the calling environment.
>
> This may need programming standards.
> But that may be the best purpose for such standards.
>
>
> What do you think ????
>
>
> Peter C
|
