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. |