Fixing SAS Evaluation Issues in Quarto

[michaelwalshe]

I was nerd sniped by your question @statasaurus on the SAS blocks not evaluating the same as previously, so investigated a bit.

I believe the change that has caused this is in the latest release of knitr, specifically yihui/knitr#2225 in https://github.com/yihui/knitr/releases/tag/v1.51 which updates so that all engines have to use their correct comment characters for quarto options, where previously R style options (i.e. #| eval: false) would work as a fallback. This, combined with the fact that SAS is a valid knitr engine (even without {sasquatch} it tries to run SAS from the command line), means we need need to change our style of including SAS code.

To fix this more permanently, we can use a couple of options. Firstly we can correctly include SAS comment style execution options, from testing on my system the following will work (note the star at the start and semicolon at the end of the option):

```{sas}
*| eval: false;
DATA BHR;
   SET BMLE;
   Bound_UA_HR=exp(-Bound_UA);
   Bound_UB_HR=exp(-Bound_UB);
   LABEL BOUND_UA_HR="Upper Alpha (HR)" BOUND_UA_HR="Upper Beta (HR)";
PROC PRINT LABEL;
   VAR _Stage_ _InfoProp_ Bound_UA Bound_UB Bound_UA_HR Bound_UB_HR;
RUN;
```

Alternatively (and my preferred option) as no SAS executable is installed in Github Actions and we haven't (and likely won't?) setup with a SAS engine using e.g. onDemand for Academics,
we can just set the SAS code blocks to render as markdown by removing the braces {}

```sas
PROC SEQDESIGN BOUNDARYSCALE=MLE ERRSPEND;
   DESIGN NSTAGES=2 
          INFO=CUM(0.748936170212766 1.0) 
          ALT=UPPER 
          ALPHA=0.0125 
          BETA=0.05
          METHOD(ALPHA)=ERRFUNCOBF 
          METHOD(BETA)=ERRFUNCGAMMA(GAMMA=-10)  
          STOP=BOTH(BETABOUNDARY=NONBINDING);
   SAMPLESIZE MODEL=TWOSAMPLESURVIVAL(
          NULLMEDSURVTIME=9.4
          HAZARDRATIO=0.6
          ACCTIME=24 
          FOLTIME=10
          LOSS=EXP(HAZARD=0.018595295942851)
          WEIGHT=1);
  ODS OUTPUT Boundary=BMLE SampleSize=SS SampleSizeSummary=SSS;
RUN;
```

Both of these work in my tests, and mean that we can remove the global yaml options setting execute: eval: false for all code, and then turning it back on for nearly all code blocks which is an awkward workflow.

I also recommend that we remove {sasquatch} from renv as a dependency, as the only file using it is rounding.qmd which doesn't actually execute any of the {sasquatch} code.

Let me know if these changes make sense, and I can make a PR updating the SAS/R code blocks to reflect it (I think most of the changes can be find/replace, and I can render the site locally so will be able to check it all works). I'll also update the templates to make it clear that that's how SAS code should be included in a comparison doc.

[loganjohnson0]

Hi! Those changes to the rounding.qmd were mine! And sorry I've disappeared for a while from this repository, but I think your comments are very spot on. Some of my motivation for making changes with sasquatch was to standardize SAS outputs and ensure their format and appearance are consistent on the website. I only tested it in the rounding.qmd file because I figured that would be the least harm area to try.

What I like about the current rounding.qmd file is that the SAS code appears as a code block rather than just Markdown text (as your Quarto issue discusses). And then the SAS code output is rendered as typical SAS output, which can be selected and filtered to only show specific SAS outputs with the sasquatch package. And the SAS outputs are at a much higher resolution than most other images on the website, and they are consistent in style.

What I don't like about the current approach is that it kind of duplicates the code, requires more complex Quarto tricks to display the SAS code while also executing it through sasquatch, and then saves the results as an RDS object that is loaded and included in the final HTML output.

Given the limitations in Quarto/pandoc/KDE with displaying SAS code blocks, I do think having the SAS code chunks use

```default
```

syntax instead of

```{sas}
```

syntax is a benefit, as it renders much better on the website.

I agree that sasquatch should be removed from the renv environment. I never meant for it to end up in it, so that's probably my bad!

What if there is a way to have a sasquatch type folder that is separate from the SAS and Comp folders? And then maybe the sasquatch folder could contain the more complex Quarto scripts that are rendered only locally; those changes could be pushed to the repository and then rendered on the website? I imagine there is a way to keep the SAS and Comp folders in sync with this new sasquatch folder (potentially via GitHub Actions or some magic of {{ includes }}) to share the content between the two without manual edits.

I will completely concede that this approach would be more complex, but I think it's worth a discussion and potential test run. I think one reason to have the ability to render SAS code is that it tests the code's ability to run and produce the expected output, and to monitor any changes or issues with the code. When I tested some of the code in the original rounding.qmd folder or some others, there were some syntax errors that did not allow the SAS code to run. I think most of those issues were missing ; or something similar, but they are relevant given that this repository aims to share code for comparing different programming languages and their outputs.

Furthermore, it would likely fall to one or two people to continue implementing the changes to the SAS code locally and to update it frequently. So, my suggestion isn't really strong, but I just wanted to offer some other ideas! Happy to discuss more and offer an attempt at my idea.