| 1 | | Transcribed from IRC: basically, {{{##sys#canonicalize-body}}} reorders |
| 2 | | internal definitions so that multi-valued assignments always follow |
| 3 | | normal ones. The result is always a bunch of let bindings to introduce |
| 4 | | the vars followed by a bunch of {{{##core#set!}}} nodes to assign them, |
| 5 | | but the normal and multi-valued var/val pairs are accumulated in |
| 6 | | separate lists so the ordering gets lost. Then, the templating just |
| 7 | | blindly puts the multi-valued {{{##core#sets!}}} after the others. |
| 8 | | Currently, the "dimensions" of the lists are different, so to speak -- |
| 9 | | in the code, vars/vals gets a list of variables/expressions, whereas |
| 10 | | mvars/mvals gets a list of lists of variables/expressions -- and |
| 11 | | mvars/mvals has to be processed a bit more to produce a c-w-v. |
| | 1 | Transcribed from IRC: basically, {{{##sys#canonicalize-body}}} reorders internal definitions so that multi-valued assignments always follow normal ones. The result is always a bunch of let bindings to introduce the vars followed by a bunch of {{{##core#set!}}} nodes to assign them, but the normal and multi-valued var/val pairs are accumulated in separate lists so the ordering gets lost. Then, the templating just blindly puts the multi-valued {{{##core#sets!}}} after the others. Currently, the "dimensions" of the lists are different, so to speak -- in the code, vars/vals gets a list of variables/expressions, whereas mvars/mvals gets a list of lists of variables/expressions -- and mvars/mvals has to be processed a bit more to produce a c-w-v. |
