Update Coding environment

Coding-environment.md

@@ -38,6 +38,18 @@ Next let's try to collect various language options, with their pros and cons:
   - ⇓ Clunky comprehensions (see the examples on the home page) and dicts are not in the language, but rather in the library. (Based on one small slightly hard to find section in the manual, {"a": "b", "c": "d"} is a literal representation for a fixed-length array of pairs of strings, apparently in an effort to be agnostic to different possible dict-like implementations. So in particular, the types in each pair have to match, and all pairs must be the same type.)
   - ⇓ Some odd rigidity, such as indentation for continuing expressions is only allowed in certain special places like after a binary operator or a parenthesis. Araq, the "benevolent overlord" of Nim, definitely displays his opinionated rigidity on the forums. Of course, maybe that's what it takes to see a new language through to success...
   - (Bottom line, there will definitely be a number of very unusual idiosyncrasies with nim such as foo_bar being the **same** identifier as foObaR that will at least require getting used to or maybe even working around. But it's not clear that any are showstoppers.)
+  - +- Has significant in-language syntax-aware macro facilities, which is a blessing and curse. We may be able to use it to provide more comfortable syntax for some of the idiosyncrasies that rub us the wrong way; but on the other hand, we could end up making our code sort of non-standard and therefore tricky for someone from the Nim language community such as it is to read intuitively...
+  - It's sad that the "where continuing expressions can break" decision is just wrong ;-) -- there's lots of discussion about this sort of thing on the web, but the overall synthesis seems to be that for several reasons
+```
+   myvar = longThing
+      + otherLongThing
+```
+is better than
+```
+   myvar = longThing +
+      otherLongThing
+```
+The gist of the most significant argument for the upper version is that one reads the beginnings of lines more easily (they are aligned, after all), and looking there it's easy to see how the parts of the long expressions are connected, and hence code written in the upper style is easier to understand. Perhaps Nim is still new/flexible enough that we could contribute a PR to _also_ make the split+indent  just before a binary operator legal as well, backwards-compatibly still allowing a split+indent after a binary operator? I think if we go with Nim I would like to try to do that. But we can wait until after we make the decision as to which language to start the "full implementation" in.
 
 ### Lobster
   * (Is this worth a more careful comparison with Nim, or is it just too small/fringe?)