On Wed, Feb 25, 2009 at 6:09 PM, Eric Northup <[email protected]> wrote: > I think mixfix could be regarded as syntactic sugar to be possibly added > later, guided by experience using the non-s-expression surface syntax. > Programmers have real problems with just the standard operator > precedence rules in C-like languages ('&' vs '==', etc)!
This is true at least partly because the C precedence ordering is counter-intuitive. The problem with this assertion about readability is that it is highly domain dependent. In the domain of systems programming, we don't need much more than four-function arithmetic and boolean algebra. We are content with current support largely because it comes built in to all modern languages. In other domains, and in higher-order programming idioms, other operators become highly desirable. They can certainly be misused, and this can result in readability failure. They can also be used appropriately, significantly *improving* readability. This will be increasingly true as use of Unicode spreads in programming editors. > Given that > BitC is aimed at reliable software development, it seems like making the > parse of a particular screenful of BitC dependent on the state of the > current operator table (not visible on the screen) could only serve to > reduce assurance. As you know, I used to agree. I no longer do. My feeling today is that this sort of audit should be supported by a decent pretty-printer, and that enforcing judicious use of mixfix can be handled as a social matter. But a key assumption I am making is that import of notation should be separable from import of identifiers. The mere fact that *you* found matrix algebra notation comforting should not mandate that I be a victim of it. One effect of this is that it makes the prevailing notation locally visible in each source file, and it allows the auditor to understand directly what notation is in force at any given point. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
