Re: Languages that are hard to parse

Hans-Peter Diettrich wrote:
> glen herrmannsfeldt wrote:
>
> > To me, reserved words are used to make parsing easier, and not to
> > make programs easier to write.
>
> Reserved words also make programs easier to read (understand). Not
> only to parsers.


In some sense, but note that the problem in legibility (as opposed to
writability) is when the programmer uses the keyword in an unexpected
fashion. But keywords are not the only words that can be used in an
unexpected way. Is an unexpected use of a language defined keyword,
i.e.
      if (if) then ...
any worse than using a language defined function
      if (cos) then ...
in term of legibility?


In practice programers almost always avoid writing obviously difficult
to understand code. Competent Fortran programmers never would write
either construct, although both were allowed by the language, and when
SELECT etc. were added to the language on updates of the code they
would replace the words that were now keywords by something that was
less confusing, but could do that replacement on their own schedule.
Revisions of C and C++, on the other hand, decided to avoid increasing
the number of keywords, in order to avoid conflicts with existing
programs, by reusing existing keywords in different contexts, with
different semantics, which has its own impact on legibility.


The real problem is not reserved versus unreserved, but the number of
language defined words, and the extent to which they match words
(english speaking) programers would like to use for variables etc.
This was a particular problem for COBOL because of its desire to have a
language as close to written english as possible, and to PL/I because
of its desire to parallel COBOL in its business domain.


> [But they make them far harder to write. The reason that PL/I
> doesn't have reserved words is that COBOL has a huge list, so that
> programmers either need to keep a chart of them on the office wall
> to consult every time they invent a new name, or be sure every name
> includes a hyphen or digit to be sure it doesn't collide with
> one. -John]


Part of this was simply the large number of words in the language,
part of this was the lack of knowledge in namespace control at the
time of the development of COBOL and PL/I. If many of the facilities
provided by these words were not made part of the explicit syntax, but
were rather put into libraries with well defined namespace control
(even something as crude as C's header files) many of these conflicts
could be avoided without the comparable parsing issues. (Mind you
while namespace control would help with writability, it might still
leave readability issues.)

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