SASPy and the Macro Processor

[Quentin]

Thanks @sastpw that makes complete sense that automatic macro quoting is a useful feature for Pythonic folks, and that's the goal of SASpy.  I wasn't thinking from a Pythonic perspective.

I would still vote for %BQUOTE by default instead of %NRBQUOTE, because I don't think %NRBQUOTE adds any value vs %BQUOTE.  And in this case %NRBQUOTE is causing a problem.  But that's just quibbling.  The choice to have automatic default quoting makes sense, and you've added (and documented) features to allow folks to who understand macro quoting to implement whatever they need.

[sastpw]

That's for your understanding @Quentin . From the SAS doc for %BQUOTE, it states: In addition, %NRBQUOTE masks: & %.

So, again, it's just to allow Python strings to be used in SAS as they are, not interpreted/converted as/to something different - by default.

SAS is tough in that there are multiple ways to get the same behavior from different things and to get different behavior from the same thing! 

[Quentin]

---

@sastpw wrote:

That's for your understanding @Quentin . From the SAS doc for %BQUOTE, it states: In addition, %NRBQUOTE masks: & %.

So, again, it's just to allow Python strings to be used in SAS as they are, not interpreted/converted as/to something different - by default.

SAS is tough in that there are multiple ways to get the same behavior from different things and to get different behavior from the same thing! 

---

%NRBQUOTE doesn't actually mask & or % which look to SAS like macro triggers, sadly.  I've read the docs on %NRBQUOTE too many times to remember.  The current docs (https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.4/mcrolref/p0frhtfqvguv78n1owh5wfeopdrj.htm )just say:

The %NRBQUOTE function is useful when you want a value to be resolved when first encountered, if possible, but you do not want any ampersands or percent signs in the result to be interpreted as operators by an %EVAL function.

I think relating to &, it means that %NRBQUOTE will prevent & from meaning AND.  So if you have an & that is not a macro trigger (because it's not followed by an alpha character) and you don't want it to be interpreted by %EVAL as meaning AND, then it does that.  e.g.:

%macro nrb(meal=);
  %if %nrbquote(&meal)= %str() %then %put meal=&meal..  Eat Something!;
  %else %put meal=&meal.. Stop eating!;
%mend;
%nrb(meal=Franks & Beans)

But if you pass %nrb(meal=Franks&Beans), you'll get the unresolved macro variable warnings for &Beans, because %nrbquote doesn't stop the macro resolution attempt.

I don't understand what the docs mean about percent signs, because I don't think a percent sign is ever an operator to %EVAL.

So to me, the only use-case I've ever found for %NRBQUOTE was when a value has a solitary &.  Which I guess is a use-case, just very limited.  But I can accept that for SASPY, that could be one less call to tech support, so could be the right decision.  : )

[sastpw]

I'll say right now that I'm sure you know more about SAS Macro than I do. I've never needed to use it enough to understand all of it's obtuse functionality. As for the doc, yes, it has bit's of info scattered over different pages and sometimes it's misleading or contradicts itself in different places. The doc I was looking at about it saying & and % is just a different page. I don't know if it's accurate or not. I can't say I tested every possibility of macro strings when implementing symput. 

But, given that you can choose any or none of the various macro functions when using symput, or code any way you want with submit, and the fact that I don't make breaking changes to SASPy if I can possibly help it, I'm not inclined to change the default behavior for this and take the chance of breaking someone's code that's already working as they want and expect.

Again, I appreciate your understanding on this!

Thanks!

Tom

[Tom]

It might be useful to add options to the symput python function to add actual quotes to the values.   Then the generated macro variables could be used directly in places where SAS syntax needs a quoted value. And if you used single quotes then macro quoting would not be needed. 

Say you had the value of O'Malley mentioned in the macro documentation.  It would be nice to be able to directly create a macro variable with the value "O'Malley" or 'O''Malley' so that you could use it in code like:

where charvar = &mvar 

[mrmcdonald]

Thanks Tom! Now it makes more since why the submit() method solution by using a data _null_ statement would work and not the default symput() method.