Researcher question – what's the point of semicolons and curly braces?

[Joe Duarte via Digitalmars-d]

On Tuesday, 3 May 2016 at 12:47:42 UTC, qznc wrote:

> The parser needs information about "blocks". Here is an example:
>
>   if (x)
>     foo();
>     bar();
>
> Is bar() always executed or only if (x) is true? In other 
> words, is bar() part of the block, which is only entered 
> conditionally?
>
> There are three methods to communicate blocks to the compiler: 
> curly braces, significant whitespace (Python, Haskell), or an 
> "end" keyword (Ruby, Pascal). Which one you prefer is 
> subjective.
>
> You mention Facebook and face recognition. I have not seen 
> anyone try machine learning for parsing. It would probably be a 
> fun project, but not a practical one.
>
> You wonder that understanding structured text should be a 
> solved problem. It is. You need to use a formal language, which 
> programming languages are. English for example is much less 
> structured. There easily are ambiguities. For example:
>
>   I saw a man on a hill with a telescope.
>
> Who has the telescope? You or the man you saw? Who is on the 
> hill?
>
> As a programmer, I do not want to write ambiguous programs. We 
> produce more than enough bugs without ambiguity.

Thanks for the example! So you laid out the three options for 
signifying blocks. Then you said which one you prefer is 
subjective, but that you don't want to write ambiguous programs. 
Do you think that the curly braces and semicolons help with that?

So in your example, I figure bar's status is language-defined, 
and programmers will be trained in the language in the same way 
they are now. I've been sketching out a new language, and there 
are a couple of ways I could see implementing this.

First, blocks of code are separated by one or more blank lines. 
No blank lines are allowed in a block. An if block would have to 
terminate in an else statement, so I think this example just 
wouldn't compile. Now if we wanted two things to happen on an if 
hit, we could leave it the way you gave where the two things are 
at the same level of indentation. That's probably what I'd settle 
on, contingent on a lot of research, including my own studies and 
other researchers', though this probably isn't one of the big 
issues. If we wanted to make the second thing conditional on 
success on the first task, then I would require another indent. 
Either way the block wouldn't compile without an else.

I've been going through a lot of Unicode, icon fonts, and the 
Noun Project, looking for clean and concise representations for 
program logic. One of the ideas I've been working with is to 
leverage Unicode arrows. In most cases it's trivial aesthetic 
clean-up, like → instead of ->, and a lot of it could be simple 
autoreplace/autocomplete in tools. For if logic, you can an 
example of bent arrows, and how I'd express the alternatives for 
your example here: 
http://i1376.photobucket.com/albums/ah13/DuartePhotos/if%20block%20with%20Unicode%20arrows_zpsnuigkkxz.png