On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:
On 5/2/2016 8:48 PM, Joe Duarte wrote:
Why are curly braces and semicolons necessary? What
information do they
carry that a compiler could not otherwise reliably obtain?
You are correct in that they are (mostly) redundant. Some
ambiguities can arise because D is not a whitespace delimited
language. However, the real reasons are:
1. Redundancy in specification means the compiler can catch
more 'typo' mistakes rather than having them compile
successfully and then behave mysteriously. If a language has 0
redundancy, then any 8745b48%%&*&hjdsfh string would be a valid
program. Redundancy is a critical feature of high reliability
languages.
Many languages have removed redundancy only to put it back in
after bitter experience. The classic is implicit declaration of
variables.
2. The redundancy also means the compiler can 'resync' itself
to the input once a syntactic error is detected.
3. It's instantly familiar to those who program already in
"curly brace" languages.
Your point about redundancy is interesting. I assume typos aren't
random, and I wonder if anyone has researched the patterns there,
which could inform where PL designers would want to insert
guards/redundancy with syntax. I wonder if I could dig into this
with GitHub and BitBucket repos. Maybe other researchers already
have.
I'm also thinking that braces and semicolons might be satisfying
to some (most?) programmers as an element of real or perceived
rigor or safety, independent of the redundancy issue. For
example, I'm a bit surprised by how popular SASS/SCSS is compared
to Stylus (CSS preprocessors), given that SASS requires a lot of
braces and semicolons while Stylus requires neither and has what
I've been calling "clean" syntax. There could be feature
differences I don't know about, but I wonder if people feel less
safe with plain, unadorned text.
I remember that Rob Pike explained why Go requires braces by
recounting how at Google their tools sometimes lost or damaged
the indentation in Python source files, breaking those programs.
I would think that you'd just fix your tools in that case. People
build such amazing software these days that I'm surprised there'd
be any issue in nailing down software that handles text files
without messing up their whitespace or other syntactic structure.
I don't know, maybe this is a recurring challenge. In any case,
your redundancy point stands on its own.
