1. If you're going to make indentation significant, implement it in a way that makes tab/space confusion impossible. Python 2.7 does this.
The check for indent ambiguity between two strings is:<p>- Remove the common leading whitespace of both strings.<p>- The remaining parts of both strings must be all tabs, all spaces, or empty.<p>This is the least restrictive rule which catches all indent ambiguities.<p>2. Indent-based syntax is great for imperative languages, but not so good for functional languages with very long expressions. It's not
clear how to indent stuff like "a.b(x).c(y).d.e(z)", where a-e x-z may be long expressions. In LISP, the all-parenthesis syntax was so simple, and so hard for humans to parse without help, that indentation was nailed into EMACS and everybody did it that way. The indentation wasn't significant, but it was standardized.<p>Here's word wrap in Rust:<p><pre><code> s.lines()
.map(|bline| UnicodeSegmentation::graphemes(bline, true) // yields vec of graphemes (&str)
.collect::<Vec<&str>>())
.map(|line| wordwrapline(&line, maxline, maxword))
.collect::<Vec<String>>()
.join("\n")
</code></pre>
Note that the first "collect" is one level deeper in parentheses than the second one.
How would you do that with indentation only?