Kevin Reid wrote: > I think what I would do to support human auditing is allow infix > operators, but prohibit precedence and associativity; that is, > parentheses must be used around any operand of an infix operator > which is itself an infix operation. This seems to me a simple and > strong solution; source is always understandable without context, and > yet infix syntax is not limited to the traditional arithmetic operators.
That's always been my opinion too. I can appreciate the argument for customizable precedence though. If precedence is available, I would consider the use of an auditing tool. This tool would use the language's parser, preferably available as a library, to insert 'shadow brackets' so the user can see the explicit associations (similar to how editors now highlights blocks in most editors). This sounds like a useful mode for the source editor as well, and is a simple, strong solution for a language with precedence assignment. > On the other hand, stick with s-expressions; elaborate syntax is a > tarpit for design. As s-expressions are a tarpit for criticism. ;-) Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
