Re: parsability

"Robin Vowels" <>
Mon, 9 Feb 2015 00:48:09 +1100

          From comp.compilers

Related articles
Choosing a parser for Mathematica input (David Kirkby) (2010-11-07)
Re: Choosing a parser for Mathematica input (2015-02-05)
parsability (was: Choosing a parser for Mathematica input) (glen herrmannsfeldt) (2015-02-06)
Re: parsability (Robin Vowels) (2015-02-09)
Re: parsability (Hans-Peter Diettrich) (2015-02-08)
Re: parsability (2015-02-09)
| List of all articles for this month |

From: "Robin Vowels" <>
Newsgroups: comp.compilers
Date: Mon, 9 Feb 2015 00:48:09 +1100
Organization: Compilers Central
References: 10-11-017 15-02-009 15-02-011
Keywords: syntax, design, history
Posted-Date: 08 Feb 2015 11:32:25 EST

From: "glen herrmannsfeldt" <>
Sent: Friday, February 06, 2015 11:05 AM

> It seems that most computer languages are designed to be easy to parse
> by programs, but not for ease of use by people.

An interesting thought, but not really the case, except for a few languages like C.

> When computers were smaller and slower, that might have made sense,

It is in this era that great efforts were made to make programming easier for people.
And even though computer memories were measured in hundreds and thousands of words,
considerable progress was made.
In the early 1950s, simple languages were developed to simplify the task of programming,
such as Alphacode, TIP, Easicode, GIP, etc etc. Some were tagged "autocode s".
FORTRAN and GEORGE came along in the middle 1950s.
And COBOL and Algol arrived in the late 1950s.
BASIC was developed for the same purpose.

None of these (with the exception of small parts of FORTRAN) was
developed to make it easy for any parser.

Even PL/I was developed to make it easier for the programmer, though
some parts were not simple and probably not easy to parse (such as the
absence of reserved keywords)

Some features of FORTRAN were not exactly easy to parse, (blanks not
having any significance), but probably simplified the keying programs
on punch cards, though brought with it an unwitting source of
programmer errors.

> but for the computers we have today, making it easier for people
> should come first.


>> Anyway the difficulty isn't parsing x //f to get f(x). It is in the
>> separation of lexical and syntactic uses of characters like "." which have
>> multiple uses.

A number of special characters have traditionally acquired multiple uses.
The asterisk, parentheses, apostrophe, colon, period, feature heavily
on account of the limited number of characters available in equipment
of the era (48-character set, 60 character set, etc.) and continue to do so
for historical reasons.

Algol perhaps fared best with preparation equipment that provided the
mathematical symbols, though implementations were bugged by line
printers that could deal only with upper-case characters and a
restricted set of special characters.
This email contains an annoying advertisement because avast! Antivirus protection is active.

Post a followup to this message

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