Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1519

Re: parsability

Show all headers | View raw

From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
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.

Indeed.

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Choosing a parser for Mathematica input fateman@gmail.com - 2015-02-05 08:08 -0800
  parsability (was: Choosing a parser for Mathematica input) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-06 00:05 +0000
    Re: parsability and human factors "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2015-02-07 12:45 +0000
      Re: parsability and human factors glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-08 10:32 +0000
        Re: parsability and human factors "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2015-02-10 12:44 +0000
    Re: parsability "Robin Vowels" <robin51@dodo.com.au> - 2015-02-09 00:48 +1100
      Re: parsability Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2015-02-08 20:49 +0100
        Re: parsability news@iecc.com (News Subsystem) - 2015-02-09 14:37 +1100
  Re: Choosing a parser for Mathematica input Robert Jacobson <rljacobson@gmail.com> - 2015-02-06 19:04 -0800

csiph-web