> LOL I wasn't going to actually propose it.
>
> In any case, the creators of *Snap! *seem to have a different opinion:
> (Page 4 of the */Snap!/* manual
> <https://snap.berkeley.edu/snap/help/SnapManual.pdf>)
>
> I'm inclined to agree with them.

The source files are using XML in a vaguely Lisp or Smalltalk fashion:

<script x="20" y="20">
   <block s="receiveGo">
     <comment w="90" collapsed="false">front left rotor</comment>
   </block>
   <block s="comeToFront"></block>
   <block s="setHeading">
     <l>90</l>
   </block>
   <block s="doForever">
     <script>
       <block s="doIfElse">
         <block s="reportTouchingObject">
           <l>wall</l>
         </block>
         <script>
           <block s="doSwitchToCostume">
             <l>red</l>
           </block>
           <block s="doBroadcastAndWait">
             <l>front left</l>
           </block>
         </script>
         <script>
           <block s="doSwitchToCostume">
             <l>rotor</l>
           </block>
         </script>
       </block>
       <block s="turnLeft">
         <l>40</l>
       </block>
     </script>
   </block>
</script>

> As I wrote earlier:
>
>     I hope we don’t exclude any Scheme implementations because they
>     don’t fit our personal definition of Scheme.
>
>     Scheme is a living (and evolving) language with a passionate
>     community in addition to implementation communities. Let’s not
>     exclude any.
>
> If we restrict ourselves to RnRS we are poorer for it.

Agreed.

Most of the practical problems should go away if we promote the most
full-featured implementations, so that they are displayed prominently.

A related problem is that at present RnRS is not formally guaranteed to
stay in any given shape in the future. It's guarded by experienced
people. This may even be superior to formally defined constraints.

> PS Check out page 105.

"It's just a macro!" (TM)