On Wed, 2008-01-23 at 23:28 -0500, Sandro Magi wrote: > Jonathan S. Shapiro wrote: > > On Wed, 2008-01-23 at 20:48 +0000, Sam Mason wrote: > >> Is this a problem because symbols are more opaque than names? > > > > Not really. It's a problem because you can't even know how the *parse* > > will behave without full knowledge of every gritty little symbol that > > some genious library builder felt compelled to help you by introducing. > > It's an enormous (human) impediment to understanding what is going on. > > And yet, so is the use of deeply nested bracketing to implement a > sequence of operations. For instance, try working with monads without > the do-notation.
There is an enormous difference. The monad do-notation is part of the language syntax. The rules for parsing it do not move out from under you as you are reading the program. > Judicious use of operators with customizable precedence can greatly > *improve* the clarity of code, as much as it can harm it. Examples please, not assertions. Specifically: examples where we cannot solve the problem by pre-introducing a limited number of operators having language-specified associativity and precedence. > As for code analysis, I consider that a standard library deficiency. Why > isn't the language's parser available in its own standard library? How would that help the code reviewer who is attempting to review the program that has been printed on a piece of paper? It is possible to build a precedence-sensitive pretty printer, but the simple fact that you need to do such a thing in order to read the code robustly on a piece of paper is a strong indication that there is a problem. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
