Grammars for future languages

schinz@guano.alphanet.ch (Michel Schinz)
Sun, 22 Oct 1995 19:00:57 GMT

          From comp.compilers

Related articles
Grammars for future languages schinz@guano.alphanet.ch (1995-10-22)
Re: Grammars for future languages torbenm@diku.dk (1995-10-24)
Re: Grammars for future languages mfinney@inmind.com (1995-10-24)
Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-10-26)
Re: Grammars for future languages wdavis@dw3f.ess.harris.com (1995-10-26)
Re: Grammars for future languages timd@Starbase.NeoSoft.COM (1995-10-30)
Re: Grammars for future languages jaidi@technet.sg (1995-11-09)
[27 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: schinz@guano.alphanet.ch (Michel Schinz)
Keywords: syntax, design
Organization: home
Date: Sun, 22 Oct 1995 19:00:57 GMT

The grammars of the majority of today's programming languages (C[++],
Ada, Pascal, Eiffel, Dylan, etc.) are Algol-like. By this, I mean that
they have a different syntax for almost every concept and special
support for arithmetic operators.


However, there are (at least) two main exceptions: Lisp-like grammars
and Self/Smalltalk-like grammars.


Algol-like grammars are believed to be easier to understand and closer
to the usual (mathematic) notations and english. On the other hand,
they have problems: they are big (hard to learn and remember) and the
operator/function-call distinction is a big problem. For example, in
C++ you can overload existing operators but you cannot define new
ones. In Eiffel, you can define new operators, but you cannot define
their priority and associativity.


On the other hand, Lisp-like and Smalltalk-like grammars are very
simple: only one or two notation are used for everything. However,
the notations used for arithmetic operations do not conform to the
mathematical notation.


For example, many people think that this (Ada) statement:


  if a=2 then
      Put_Line("A = 2");
  else
      Put_Line("A /= 2");
  end if;


is easier to understand than this (Self) one:


  a=2 ifTrue: [ stdout write: 'A = 2' ]
            False: [ stdout write: 'A /= 2' ].


or this (Lisp) one:


  (if (= a 2)
          (write-line "A = 2")
      (write-line "A /= 2"))


My claim is that this may be true for people who already know a
"classical" programming language (Pascal, Basic, etc.) but I do not
think that this is true for complete beginners, who certainly do not
understand any of them. I even think that complete beginners will
understand simple (i.e. Lisp- or Smalltalk-like) grammars quicker,
precisely because of their simplicity. To quote the "candygrammar"
entry in the Jargon File 3.2.0:


    This intention comes to grief on the reality that syntax
    isn't what makes programming hard; it's the mental
    effort and organization required to specify an algorithm
    precisely that costs.


For example, I remember clearly that when I learned my first
"programming language" (Commodore 64 Basic :-), I had troubles
understanding the concepts, not the syntax.


Also, even if being close to the mathematical notation was once very
important, because the vast majority of programs used mathematics a
lot, this isn't true anymore. Ok, there are still a lot of
mathematical programs, but there is also a wide range of computer
applications which simply do not need a special notation for
arithmetic operations (compilers are an example).


Simple and uniform grammars also have a great advantage when one wants
to add new features to a language, like object-oriented capabilities.
With simple grammars, user-defined constructs look just like
predefined constructs. That means that it is possible to add new
language features without modifying the grammar, and thus the
compiler. For example, it is possible to add OO-capabilities to
Lisp-like languages (see for example CLOS) without modifying the
compiler at all. On the other hand, you can't make a C compiler
compile C++ code without modifying it, because new grammar constructs
are needed for the OO-features. (Ok, I agree, this argument has some
weak points: it is not just because of its grammar that
OO-capabilities can easily be added to CommonLisp: macros and other
things are required. Also, it might be possible to add OO-capabilities
to C without new grammar constructs. But the fact is that this is not
the way it has been done, and I think that the grammar is one of the
main cause of this situation.)


I therefore think that grammars for new languages should not be
Algol-like but Lisp- or Smalltalk-like (or anything similar).
Obviously, however, some people do not agree on this. For example,
Dylan's original Lisp-like grammar was changed to a Pascal-like
grammar. I would be interested to know why, and also I would like to
know what language designers think about this issue.


I think that this issue is an important one, because if all new
languages are designed to have a simple grammar, parsing could slowly
become much easier, and its importance in compilation would decrease.


Thanks,
Michel.
--
Michel Schinz (schinz@alphanet.ch -or- schinz@studi.epfl.ch)


Please don't send long files by mail, since we pay.
--


Post a followup to this message

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