[bitc-dev] Issues for s-block surface syntax

[Jonathan S. Shapiro]

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