Yes, this clarifies everything, thanks! Some more comments/thoughts.
I would suggest adding a @(table-of-contents) to the top of every page: it helps the reader know what is coming ahead. For instance, it's good for me to know up front that I don't have to understand sec 1 all by myself, because you will explain it to me in sec 2. This is very helpful when you have biggish sections: e.g., http://papl.cs.brown.edu/2017/set-representations.html [Yes, this is what the gutter at hte left says. Me, somehow, I always ignore that gutter, because on most Web sites it's irrelevant.] (Not exclusively, the text could also just have a forward reference in the prose of sec 1 itself.) Your (lack of) op precedence I find a little confusing, a bit curiously given that I'm designing a language with the same op precedence. In Pyret we have no op precedence, but we allow a sequence of the same binop to not need parens; everything else needs to be parenthesized. We've used this for years now with students and it has been received well because it's simple and consistent. For instance, if I write fun D1(prey): (prey-growth-rate * prey) - predation-rate * predators * prey end fun D2(predators): (predator-growth-rate * predators * prey) - predator-loss-rate * predators end I get the error, in both D1 and D2, The * operation is at the same level as the - operation. Use parentheses to group the operations and to make the order of operations clear. so I'd instead have to write fun D1(prey): (prey-growth-rate * prey) - (predation-rate * predators * prey) end fun D2(predators): (predator-growth-rate * predators * prey) - (predator-loss-rate * predators) end My concern is that in your case, position really matters, with two consequences: 1. The reader has to internalize the rule, which (if they're coming from just having programmed in something else) they may not even realize — these kinds of rules are a form of mode-switching, and we know from HCI that humans are really bad at it. 2. Refactoring becomes annoying: if I add something to the left of an existing expression, suddenly its parsing might have changed. So it's safer to just parenthesize things. The last line above drove the design of Pyret. It *is* safer to just parenthesize, but long chains of the same operator do happen a fair bit, and they're annoying to fully parenthesize. So we struck a compromise that has worked very well. Shriram -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
