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
