Re: simple vs complex languages

Nick Maclaren wrote:
>
> Grrk. I don't think that this is quite it. Most natural languages
> have a very simple syntax, but what they don't have is either a
> well-defined separation between syntax and semantics or a precise
> definition of what is valid syntax. English is extreme in both cases.


This is very true. When computer languages skirt the edge of
ambiguity, people often write things they think are correct, but which
are actually logical errors. For example, most people assume
left-associative exponentiation, but right-associative exponentiation
is also a valid interpretation of the mathematics and concepts
involved.


So if your language has an exponentiation operator, you have to make
an explicit decision and specify it: is exponentiation
left-associative, right-associative, or do you require parens or the
equivalent to make it explicit? And after getting bitten a few times
anyway, which inevitably happens, most programmers learn to use
parentheses defensively, to prevent exactly that kind of ambiguity,
even when the language has a rule for resolving it. That is, even in a
language that has a rule for resolving a semantic ambiguity, people
have to think about it and defend against misinterpretation - as much
by themselves as by the language system.


I've been bitten this way by C's address-of and dereferencing
operators not associating the way I expect them to and requiring
parentheses to disambiguate, many times. And now I just use parens as
part of those operators because I don't want to sweat out some obscure
bug caused by me taking one view of how something would be parsed and
the compiler taking another (my LISP background shows here, I guess).


> The need for programming, as with mathematics and serious science, is
> something that is precise and unambiguous.


It goes a little beyond that. It's not merely something that's
precise and unambiguous, it's also ideally something that doesn't map
to ambiguous concepts and ideas in the human brain. And that's much
harder to accomplish. In natural languages, I think a word's ambiguity
is often a vital and irreducible part of its meaning; if we pick just
"one meaning or the other" we lose a nuance of what's being
communicated. IOW, I think ambiguity is a very important feature of
human communication (This is an unorthodox opinion, but I have a lot
of professional experience, mostly in natural-language software, and
it seems true to me). I can't easily imagine wanting that kind of
dynamic in a language that specifies instructions to a machine.


> The real argument against complexity is that it leads to human
> errors and often hides ambiguity. If you can't parse it easily, then
> how can you be sure what it means?


Bingo. I think we are in total agreement here. However, there are
some nice unambiguous languages humans can parse easily (broad classes
of context-sensitive or type 0 languages) that it's very hard to build
an efficient parsing program for. And there's a legitimate question
about whether any advantage of those languages is compelling enough to
"take the hit" in parsing speed.


Bear

Return to the comp.compilers page.
Search the comp.compilers archives again.