[Grace-core] Other things that we might want to change

[Andrew P. Black]

Since Michael has started revisiting some of the language details that we decided long ago, I though that I would add a few more to the list of things to reconsider:

The\smost\srecently\sdecided\swas\sto\suse\s\s\sfor\snon-breaking\sspace\sin\sa\sstring\sconstructor.\s\s\sHaving\sgiven\sthis\ssome\smore\sthought,\sit\sseems\sto\sme\sthat \_ would\_be\_a\_lot\_more\_readable.\_This\_paragraph\_should\_illustrate\_why.
Tim Sheard and I wrote the grammar-rules for binary operators yesterday.  The current rules are really arcane — not just hard to implement but hard to explain.   The best that we could come up with (and this took more than an hour) is:  
A binary operator sequence is a sequence of simple expressions separated by operator symbols, such as  
a + b + c + d
a
a * b + c / d
a * b > d / e
Such a sequence is legal in two situations:
all of the operator symbols are identical.  In this case the operators associate to the left, as in (((a + b) + c) + d)
all of the operator symbols are drawn from the set {* / + -}.  In this case  * and / bind more tightly that + and -.  Hence a * b + c / d means (a*b) + (c/d), and a + b - c - d means  (((a + b) - c) - d)
Other sequences (like a * b > d / e) are illegal.
Tim’s comment was that it is precedence itself that is confusing, and if we are after simplicity, we should get rid of it.  
When I was rewriting minigrace’s identifier resolution pass, it became clear to me that I don’t understand the syntax of patterns.  In particular, I could not predict when identifiers in a method request with arguments were defining or applied occurrences.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150207/4d9e1271/attachment.html>