LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (October 2005, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Sun, 16 Oct 2005 01:17:01 +0000
Reply-To:     iw1junk@COMCAST.NET
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Ian Whitlock <iw1junk@COMCAST.NET>
Subject:      Re: On "Call Execute" and "Resolve": Just Curious on a Friday


In response to my statement about CALL EXECUTE:

>Bora, > >Ron and others gave you a good explanations, but I would add that CALL >EXECUTE does not execute SAS code, it executes macro code, i.e. it >generates SAS code for later execution. > You wrote,

I would say that in general, it does not generate any code. Rather, it passes along what it receives from the evaluated argument.

I think we are quibling over words. However, I think most programmers would agree that in **general** the macro facility **generates** SAS code. I would find it odd to say this is just passing along evaluated arguments. Can you site anywhere that such language is used?

Perhaps your "in general" was meant in the context of Bora's code which did not involve any macro instructions in his code that involved CALL EXECUTE. In this case, you might simplify and say the code is passed along, but even then I think it more helpful to consider it a degenerate case of code generation in which no macro processing is needed.

Incidentally my reasons for making it explicit that "CALL EXECUTE does not excute SAS code" are:

1) Some languages do provide functions for executing character strings of code.

2) The name EXECUTE suggests that the SAS function might execute strings of SAS code.

3) The example that Bora gave showed that he expected the string 'my_var' || trim(left(my_index)) to be SAS evaluated, i.e. executed in the step by SAS.

Ian Whitlock

Back to: Top of message | Previous page | Main SAS-L page