Re: simple vs complex languages

Robert A Duff <bobduff@shell01.TheWorld.com>
15 May 2003 12:34:46 -0400

          From comp.compilers

Related articles
[11 earlier articles]
Re: simple vs complex languages torbenm@diku.dk (2003-05-12)
Re: simple vs complex languages spencer@panix.com (David Spencer) (2003-05-12)
Re: simple vs complex languages thant@acm.org (Thant Tessman) (2003-05-12)
Re: simple vs complex languages bear@sonic.net (2003-05-12)
Re: simple vs complex languages bear@sonic.net (2003-05-12)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-05-14)
Re: simple vs complex languages bobduff@shell01.TheWorld.com (Robert A Duff) (2003-05-15)
Re: simple vs complex languages lex@cc.gatech.edu (Lex Spoon) (2003-05-15)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-05-16)
Re: simple vs complex languages dot@dotat.at (Tony Finch) (2003-05-16)
Re: simple vs complex languages tenger@iSeries-guru.com (Terrence Enger) (2003-05-16)
Re: simple vs complex languages alexc@std.com (Alex Colvin) (2003-05-16)
Re: simple vs complex languages eas-lab@absamail.co.za (2003-05-18)
[21 later articles]
| List of all articles for this month |

From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 15 May 2003 12:34:46 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 03-04-095 03-05-013
Keywords: design, parse
Posted-Date: 15 May 2003 12:34:46 EDT

Albert Hofkamp <hat@se-46.wpa.wtb.tue.nl> writes:


> On 27 Apr 2003 02:24:42 -0400, Steve_Lipscombe@amat.com <Steve_Lipscombe@amat.com> 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.


If you mean, "a syntax that is easy to parse by computer is not
necessarily easy for humans to understand", then I agree. But I think
it has *something* to do with it. A grammar that is formally
ambiguous will *tend* to be hard for humans to understand, other
things being equal.


> 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.


Good point.


> As an example, should one use , or $ and # as seperation symbol in
>
> a,b:nat, c,d:bool
>
> vs
>
> 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.


Yes, commas are better separators than $ and #, for the reasons you
imply. However, comma-separated lists of comma-separated lists are a
Bad Thing, both for parsers, and for humans. Why not:


        a, b: nat;
        c, d: bool;


with a little whitespace thrown in for readability?


> 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.


Mathematics?! The syntax of mathematics is hardly "simple". In fact, I
have never seen a grammar for (all of) mathematics. And maths papers
often introduce their own notations. And tell me where is it clearly
specified that "xy" means "x times y", whereas "cos" refers to the
cosine function, and does not mean "c times o times s"?


Anyway, maths serves a different purpose from programming languages. In
maths, we are often more worried about the structure of expressions (x
and y could refer to *anything*, and we don't care), whereas in
programming, we care about what our variables represent (Current_Salary,
or whatever).


> > 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.


I'm not sure that's entirely true. Anyway, human languages serve a
different purpose from programming languages, so analogies between the
two are somewhat suspect.


- Bob


Post a followup to this message

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