The only well justified use of <idExpr> left is in <termBase>
brianMon 6 Sep 2010
The & operator is the field storage operator, so that is ok.
The idea for <slotExpr> is a good one. The parser is actually implemented so that it doesn't make the distinction b/w locals and slots until later, but still good to improve the grammar. I pushed that changeset.
Thanks for your great feedback.
vkuzkokovMon 6 Sep 2010
You're always welcome.
The & operator is the field storage operator, so that is ok.
It's still redundant, because:
I don't know what & will mean before <parenExpr> in general case.
<field> := ["&"] <id> already, and that's the only valid case I can think of.
brianTue 7 Sep 2010
Yeah great point, it is redundant. I will remove "&" from the unaryExpr production.
vkuzkokov Fri 3 Sep 2010
Grammar page mentions
<prefixExpr> := ("!" | "+" | "-" | "&" | "++" | "--") <parenExpr>I believe
&is a curry operator, therefore obsolete.Two rules one after another look rather misleading:
It's like if we could call
obj.localwherelocalis local variable. Though, it won't change resulting grammar I think it's worth being rewritten as:The only well justified use of
<idExpr>left is in<termBase>brian Mon 6 Sep 2010
The
&operator is the field storage operator, so that is ok.The idea for <slotExpr> is a good one. The parser is actually implemented so that it doesn't make the distinction b/w locals and slots until later, but still good to improve the grammar. I pushed that changeset.
Thanks for your great feedback.
vkuzkokov Mon 6 Sep 2010
You're always welcome.
It's still redundant, because:
&will mean before<parenExpr>in general case.<field> := ["&"] <id>already, and that's the only valid case I can think of.brian Tue 7 Sep 2010
Yeah great point, it is redundant. I will remove "&" from the unaryExpr production.