On Fri, Aug 13, 2010 at 3:32 PM, Mark P. Jones <[email protected]> wrote:
> It sounds like you're thinking about this from an implementor's
> perspective....
The implementor's perspective prompted the question, certainly, but I was
actually thinking more from an auditor's perspective. I think the main
problem from a human perspective is automatic close brace insertion rather
than automatic semicolon insertion, and I wasn't contemplating that.
Assume we are in an item sequence where the opening brace was explicit.
Under these conditions, there are only three ways that a semicolon can get
automatically inserted:
1. We emitted a continuation line that is not indented relative to the
line it continues, or
2. We failed to emit a terminating semicolon at end of previous statement
*and* *over*-indented the subsequent line, such that it looks like a
continuation line.
3. We failed to emit a terminating semicolon at end of previous statement
*and* *under*-indented the subsequent line, such that it looks like the
scope should have ended.
>From a practical perspective, in my experience, all three of these
situations signal that the program likely contains an error. If automatic
semicolons are inserted, the first is likely to generate a (desirable) parse
error. The second may or may not generate a parse error depending on what we
do with curried application. The third is a place where we *would
have*auto-inserted a close brace, but are prevented from doing so. We
should
probably be treating case [3] as cause for a warning in any case, on the
grounds that no sensible coding style condones it.
So what I think I'm saying here is that well-formed code should never trip
on semicolon auto-insertion, and ill-formed code is something we want to
diagnose in any case. All that's necessary to avoid ';' insertion is to keep
the code marginally readable by lining up starts of lines. Programmers with
neurons do that anyway. I don't feel greatly constrained to support the
other kind. :-)
For program synthesis, we can either emit long lines or introduce a rule
that \ at the end of a line hides the newline. There actually is a
compelling use case for that, which is long strings in printf-like things.
But it's worth pausing to examine where issues from unicode issues might
arise. If one always places a newline after an explicit '{', one won't have
leading unicode on the next line, so there shouldn't be indentation hazards.
Alternatively, one can put the entire block on one line if it is short (as
in LET). The main cases that seems to leave are binding constructs like LET
and WHERE. If the programmer writes as input:
let { x = 5;
y = 6 }
in {
body
}
all is well. The trailing semicolon on the first line suppresses semicolon
insertion, and the explicit open curly brace suppresses automatic scope
closing.
Do you perhaps see something here that I may be missing?
Jonathan
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
