Re: simple vs complex languages

Albert Hofkamp <>
6 May 2003 01:01:05 -0400

          From comp.compilers

Related articles
Re: simple vs complex languages (2003-04-27)
Re: simple vs complex languages (Ralph P. Boland) (2003-04-27)
Re: simple vs complex languages (Alex McDonald) (2003-04-27)
Re: simple vs complex languages (Basile STARYNKEVITCH) (2003-05-05)
Re: simple vs complex languages (2003-05-05)
Re: simple vs complex languages (Albert Hofkamp) (2003-05-06)
Re: simple vs complex languages (2003-05-06)
Re: simple vs complex languages (Scott Moore) (2003-05-06)
Re: simple vs complex languages (2003-05-06)
Re: simple vs complex languages (2003-05-12)
Re: simple vs complex languages (George Richard Russell) (2003-05-12)
Re: simple vs complex languages (2003-05-12)
[33 later articles]
| List of all articles for this month |

From: Albert Hofkamp <>
Newsgroups: comp.compilers
Date: 6 May 2003 01:01:05 -0400
Organization: Eindhoven University of Technology, The Netherlands
References: 03-04-095
Keywords: parse, design
Posted-Date: 06 May 2003 01:01:05 EDT

On 27 Apr 2003 02:24:42 -0400, <> wrote:
> Robert wrote
>>The thing that bothers me about all this fancy parsing technology we
>>have developed over the past few decades is that it is solving an
>>artificial problem. If we didn't design our programming languages to
>>have such doggone complicated syntax, then we would be happy to use
>>hand-written recursive-descent parsers.
> And our moderator replied
>>[I don't see why it's artificial. Human languages have very complex
>>grammars. That's how we're wired to work. Why shouldn't computers
>>adapt to us for a change? -John]

> If a language is designed with a simple, consistent syntax then it is
> not only easier for the compiler to parse, but (more importantly) it
> is easier for humans to understand and therefore easier to get

I agree with 'simple, consistent syntax leads to easier understanding
for humans', except I don't think ease of parsing for a computer has
anything to do with it.

Humans are much better at understanding than a parser. The main reason
is that humans look at the 2D picture of a program (i.e. they look at
the entire code rather than line by line).
The layout/formatting of a program, and the visual 'weight' of symbols
is there fore much more important.

As an example, should one use , or $ and # as seperation symbol in

a,b:nat, c,d:bool


a$b:nat# c$d:nat

Syntactically, there is no difference (the latter is even better
parsable, because $ and # seperate different things), yet ease of
reading (and thus, understanding) is better in the first example.

> right. Can you guess I like Pascal, which was designed from the outset
> for a single pass RDP?

There is a big didactic problem with Pscal imho. The language pushes
the top-down design approach, yet I have to write my program
bottom-up. I think that is a very big compromise for ease of parsing.

> I'm no expert in these matters (then shut-up, they cried), but it
> seems to me that to express complex ideas we need a rich vocabulary,
> but not a complex syntax. And if not, then why do we do it?

Complex ideas can be expressed in a simple syntax. Look at
mathematics. Everything can (in the end) be expressed by a single
line of formulae, using just simple symbols.

The target audience of a language is an important factor here. If you
aim for a 'everybody can understand this' language, you need plenty of
verbose syntax. If you aim for a language that requires close attention
(like maths), verbose syntax has a habit of getting in the way of
writing down what you want to express.

> Why make anything needlessly complicated? Just to prove how clever we are?

Everybody can write 'hello world' in 1 page. The challenge is to be able
to do that with a real program without losing readability.

The main reason for wanting to have a program on 1 page is that 1 page
preserves the 2D picture for humans.
(I believe that there is a very good reason for math being the way it
is. If a verbose syntax would be helpful, they would have introduced it
a long time ago.)

That means having as little syntax as possible. A good example is the
list comprehensions in Bird&Wadler. It is incredible what one can
express with them in a single line.

The price that is paid, is the increased complexity of parsing. In
particular, bracket pairs are heavily overloaded in our language (we
should create a new ASCII char set with more types of brackets :-) ).

The current implementation is on the very edge of what YACC can handle.
For the next version, I have switched to a generic parser (sglr, to be
precise). I wouldn't know how to parse without advanced parsers.

> Human languages are complex and ambiguous not because we like them that
> way, but because they have evolved from something simple.

And apparently, we like it.
If not, we would not have evolved in that direction.

Just because it is difficult to understand a sentence from the
narrow-minded view of a parser is (for me) not a reason to restrict a

> Finally, if you want to program in a human language, try parsing this old
> favourite:
> Time flies like an arrow, fruit flies like a banana.

If you can write the semantics, I can do the parsing.... :-)


Post a followup to this message

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