Re: simple vs complex languages

tmk@netvision.net.il (Michael Tiomkin) writes:


> Steve_Lipscombe@amat.com wrote in message news:03-04-095...
> > Robert wrote


> > 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
> > right. Can you guess I like Pascal, which was designed from the outset
> > for a single pass RDP?
>
> Well, in this case you'd better use Lisp or Postscript which have
> much simpler syntax. BTW, implementing Pascal with its hierarchical
> stack structure used for nested procedures isn't very nice and
> efficient.


Besides that the stack strucure has nothing to do with syntax, it
isn't really that problematical. True, the naive approach to Pascal
implementation has all variables in the activation record always, so
they are easily accessible through nested scopes and
call-by-reference. But it isn't terribly dificult to ensure that only
the necessary variables are stack allocated, and only when this is
required (more or less, given the undecidability of anything having to
do with program behaviour). True, accessing a non-local variable is
less efficient than accessing a local variable, but the lack of nested
scopes just forces the programmer to do something equivalent by hand,
not gaining much, if anything, in efficiency.


> Recall that the purpose of inventing a programming language is to
> allow relatively short and comprehensible programs. Your primary
> target is a human who writes/reads the code. And most humans have a
> huge problem to understand things that are too simple and boring
> (attention wandering away) or too complicated (giving up).
> It seems that humans need certain level of complexity to be
> comfortable with.


This is certainly true. However, different people have different
tresholds. There is no reason why a single language can't cater to
all of these, though: Having a simple core syntax and semantics but
allowing more complex features for those who want or need them.


> You might be right that a computer would prefer to parse 5K lines of
> Lisp than 200 lines of C++. The problem is that nobody asks them what
> are their preferences. And if you can save 20K hours of work of
> programmers with just 12 hours of your work to make a decent parser
> (well, make it 200 hours for C++!-), this is an efficient use of your
> time.


I have yet to see a fully compliant C++ parser, so 200+ hours is an
understatement. Besides, C++ syntax isn't especially human-friendly,
so the example is ill-chosen. But I agree that LISP is too simplistic
in its syntax: Humans have no problem at all with infix operators of
different precedence, nor with meaning-carrying layout (such as
indentation). The latter is a mild problem for parsers, since they
normally use a formalism based on one-dimensional strings.


> > Human languages are too ambiguous for programming. They only work for
> > humans because we add redundant information, use context to resolve
> > ambiguities, or simply make assumptions (which sometimes/often turn
> > out wrong).
>
> This can be said about programming as well. Programs use redundant
> information, e.g. definitions and declaration of the same entity in
> one program. Programs use context to resolve ambiguity, e.g. using
> declarations and prototypes in order to derive program semantics.


One of the problems with C++ is the need for non-local context to
disambiguate syntax on a very fundamental level. This is not only a
problem for parsers, but also a problem for humans, since they need to
refer to this context to understand a piece of text.


Torben Mogensen

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