Stricter left-to-right evaluation order

[gilch]

One of the nice things about Python is the predictable evaluation order of subexpressions. In a pure functional language without side effects, this is not much of an issue. Python is not that. Any expression could have an effect, and the order might matter. The Hissp compiler also relies on this fact.

Macros can rewrite expressions in any order they please. Some schools of thought hold that expressions should be used in the macro in the same order written. (Other don't care, perhaps because e.g., Scheme doesn't guarantee evaluation order in most cases.) This might not be feasible in all cases but should be doable most of the time. I apparently haven't been doing this consistently. As I've moved examples around in the docs, I noticed cases where evaluation order might be surprising. I might want to fix that. I noticed this in the expansion for set! and realized it could be widespread, and thought I'd better write it down.

Off the top of my head, I can think of two options that would usually work. One is to take in the arguments in the most natural usage order. The other is to use them in argument order in a let, and then use the locals in whatever order is natural. This probably has negligible overhead in cases when I'm expanding to a let anyway, which is often. I'm not sure which is preferable. It might be a case-by-case judgement.

[gilch]

I wonder if I should also point this out in the docs somewhere, perhaps as part of a set of guidelines for writing macros well. On the other hand, if people tend to use Hissp in a pure functional style (doesn't really seem to be the case so far), then this doesn't really matter.

[gilch]

One case I've noticed this being an issue is in -> and -<>> when writing ^#. It's currently implemented in terms of stack pops, which are mutations, and they occur in the reverse of the order written due to the way threading works. I feel like these should at least have a prominent warning.