|[12 earlier articles]|
|Re: A Plain English Compiler firstname.lastname@example.org (2006-02-20)|
|Re: A Plain English Compiler email@example.com (Scott Wyatt) (2006-02-24)|
|Re: A Plain English Compiler firstname.lastname@example.org (Gene Wirchenko) (2006-03-12)|
|Re: A Plain English Compiler email@example.com (2014-10-24)|
|Re: A Plain English Compiler firstname.lastname@example.org (2014-10-25)|
|Re: A Plain English Compiler email@example.com (Derek M. Jones) (2014-10-25)|
|Re: A Plain English Compiler firstname.lastname@example.org (Martin Ward) (2014-10-27)|
|Re: A Plain English Compiler email@example.com (Kartik Agaram) (2014-10-27)|
|Re: A Plain English Compiler firstname.lastname@example.org (Kaz Kylheku) (2014-10-27)|
|Re: A Plain English Compiler email@example.com (Ivan Godard) (2014-10-27)|
|Re: A Plain English Compiler firstname.lastname@example.org (Martin Ward) (2014-10-28)|
|Re: A Plain English Compiler email@example.com (Stefan Monnier) (2014-10-28)|
|Re: reading and writing, was A Plain English Compiler firstname.lastname@example.org (Stefan Monnier) (2014-10-28)|
|[9 later articles]|
|From:||Martin Ward <email@example.com>|
|Date:||Mon, 27 Oct 2014 11:54:43 +0000|
|References:||06-02-122 06-02-125 14-10-005|
|Posted-Date:||27 Oct 2014 15:04:08 EDT|
On 25/10/14 00:33, firstname.lastname@example.org wrote:
> [Note that this is a followup to some messages from 2006. See
> http://compilers.iecc.com/comparch/article/06-02-122 - 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.box.right = (picture.gpbitmap.width - 1) * tpp
picture.box.right = 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:
COMPUTE RIGHT OF BOX OF PICTURE = (WIDTH OF GPBITMAP OF PICTURE - 1) * TPP
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
email@example.com http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc
Return to the
Search the comp.compilers archives again.