Re: A Plain English Compiler

Martin Ward <>
Mon, 27 Oct 2014 11:54:43 +0000

          From comp.compilers

Related articles
[12 earlier articles]
Re: A Plain English Compiler (2006-02-20)
Re: A Plain English Compiler (Scott Wyatt) (2006-02-24)
Re: A Plain English Compiler (Gene Wirchenko) (2006-03-12)
Re: A Plain English Compiler (2014-10-24)
Re: A Plain English Compiler (2014-10-25)
Re: A Plain English Compiler (Derek M. Jones) (2014-10-25)
Re: A Plain English Compiler (Martin Ward) (2014-10-27)
Re: A Plain English Compiler (Kartik Agaram) (2014-10-27)
Re: A Plain English Compiler (Kaz Kylheku) (2014-10-27)
Re: A Plain English Compiler (Ivan Godard) (2014-10-27)
Re: A Plain English Compiler (Martin Ward) (2014-10-28)
Re: A Plain English Compiler (Stefan Monnier) (2014-10-28)
Re: reading and writing, was A Plain English Compiler (Stefan Monnier) (2014-10-28)
[9 later articles]
| List of all articles for this month |

From: Martin Ward <>
Newsgroups: comp.compilers
Date: Mon, 27 Oct 2014 11:54:43 +0000
Organization: Compilers Central
References: 06-02-122 06-02-125 14-10-005
Keywords: design, parse
Posted-Date: 27 Oct 2014 15:04:08 EDT

On 25/10/14 00:33, wrote:
> [Note that this is a followup to some messages from 2006. See
> - John]
> We've decided to take this thing to its logical conclusion. See

John said (back in 2006) "You can certainly chop English down to
a small unambiguous subset, but then you've just reinvented Cobol"

As someone who has had to work with COBOL somewhat, it is interesting
to compare the two languages:

"Plain English" is even more verbose that COBOL, for example:

      put the picture's gpbitmap's width minus 1 times the tpp into the
picture's box's right.

I assume that this means: = (picture.gpbitmap.width - 1) * tpp

and not: = picture.gpbitmap.width - (1 * tpp)

since the latter has a redundant multiplication.
This means that multiplication does not take precidence
over addition in "Plain English" (unlike in mathematics).

The language does not have formulae at all (unlike COBOL), although
these are planned to be added. When formulae are added, I assume that
they will follow the usual rules of arithmetic: in which case the
discrepency between the "verbose" style and the "formula" style will
become even more confusing!

In COBOL, the above statement could be written:


COBOL has a large number of machine-independent data structures:
strings, packed decimal, binary decimal and floating point.
For example, packed decimals can have up to 31 digits plus
a (fixed) decimal point and a sign. So you can process numbers
up to 9,999,999,999,999,999,999,999,999,999,999.
"Modern" COBOL (i.e. COBOL 2002 and later) includes bit manipulation,
recursion, user-defined functions and other features.
(Although, IBM has not yet implemented COBOL 2002 in their mainframe
compiler: having only had 12 years or so to work on it!).

"Plain English" only has 8 bit unsigned and 16 and 32 bit signed
binary numbers, 32 bit pointers, strings and records.
So "Plain English" cannot handle any number bigger than 2,147,483,648.
There are also "ratios" which appear to be represented as a signed
numerator and unsighed denominator. I don't know what you do if you
want to address more than 4GB of RAM, or, for that matter, work with
floating point numbers!

Strings appear to be represented using the Windows-1252 character set
-- no Unicode for you!

In old-fashioned (pre-2002) COBOL you had to use a whole byte to
implement a flag: or encode several flags into one data item with some
complicated coding to access and update them. In "Plain English" a
single flag takes 32 bits of storage: which seems a step backwards to

"Plain English" has numeric operations: plus, minus, times and divided
by (with optional remainder), but no power operation.

Finally: there are no nested IF statements and no nested loops.
How do you process a two-dimensional array without a nested loop?
Well, since there are no two-dimensional arrays in the language,
(or even one-dimensional arrays, for that matter), you don't have
to worry about that!

Routines can declare local data: but since each routine has to be
extremely short (due to the lack of nesting of conditionals
or loops), any time you need a nested conditional or loop
you have to split the code into separate routines: which means
that any shared data has to be global variables!


Dr Martin Ward STRL Principal Lecturer & Reader in Software Engineering Erdos number: 4
G.K.Chesterton web site:
Mirrors: and

Post a followup to this message

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