John, Functional ways would be an approach I would admire and +1 for. I like the alternative also. In OpenRefine with the GREL expression language, we did something similar.
Parenthesis rule. Go Lisp. err, wait, Go Go. Oops, wrong business... Go Rust ! On Thu, Apr 25, 2013 at 1:46 PM, John Clements <[email protected]>wrote: > Huh? Looks like my first message didn't go through. Perhaps I'm being > moderated, and I just didn't know it? > > Apologies if this appears twice. > > Per our meeting today, I'm sending this out to see whether we want to make > a change. > > Currently, our grammar parses > > if (true) {3} else {4} + 10 > > As a statement followed by a (non-parseable) expression. This is to > prevent things like > > if (true) {3} else {4} > |a| {foo()} > > … from being parsed as two uses of the "or" operator, for instance. The > basic restriction is that when something that could be a statement occurs > in a position where it could be a statement, then it should be parsed as a > statement and not as an expression. > > Keep in mind that you can always force a statement-y thing to be allowable > in any position by using parens. So, for instance, > > (if (true) {3} else {4}) + 10 > > is a perfectly legitimate expression. > > This restriction is the cause of no small ugliness in the grammar. > > Simplifying it might concievably avoid certain errors. However, it would > probably make some people unhappy. > > One way to fix it would be simply to lift the restriction entirely. In > this case, > > if (true) {3} else {4} > |a| {foo()} > > … would be parsed as > > ((if (true) {3} else {4} > |a) > | {foo()}) > > … which some people might be surprised by. > > Another solution would be to *always* require semicolons, even after > blocks. This would probably make lots of people immediately unhappy. > > Another solution, the "shift the burden to those kooky functional folks", > would be to say that using a statement as an expression *only* works when > it's enclosed in parens. This would simplify things a lot. This would not > change the behavior of the first example at all, but it would for instance > rule out > 14 + if (true) {3} else {4} > … requiring instead > 14 + (if (true) {3} else {4}) > But indeed, I think I would probably opt for the latter one as more > readable anyway. > Another example that would have to change would be changing something like > for foo.each |a| {f(a)}.bar() > into > (for foo.each |a| {f(a)}).bar() > But honestly, that one makes me happier as well. > > The more I think about this alternative, the more I like it. > > Either way, this ship's gangplank is up and it's straining at its hawsers. > We should probably make a decision on this now-ish. > > John > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
