Re: Writing A Plain English Compiler

Bartc says,
I've looked at your project in a little more detail. It seems quite
interesting, but I think the Plain English aspect is obscuring the
rest of the project. It's an odd mix of high and low level features, for
example there is
even some inline machine code in there! (In 'the noodle', so perhaps
it isn't implemented quite 100% in itself, unless this is some
temporary bootstrapping or other code.) Then there are direct calls to
Win32 functions.


Gerry replies,
We realize that English isn't the most convenient or effective way of saying
everything, but we didn't have time to implement the "hybrid" programming
language that we ultimately envision. So we settled for a mix of the "very
highest" (English) and "very lowest" (machine code) as a "proof of
concept" -- and because it was necessary (a compiler has to put out machine
code somewhere). Thus, in the noodle and the compiler we end up with such
things as:


To add a number to another number:
Intel $8B85080000008B008B9D0C0000000103.


Which is closer to our envisioned Hybrid language than strict Plain English.


Bartc says,
Plus there is lots of code that would be written in pretty much the
same way in nearly every other language, but the need to pretend it is
plain English just adds clutter. One example:


a uuid is a record with
        a number called d1,
        a wyrd called d2,
        a wyrd called d3,
        8 bytes called d4.


(I would guess someone savvy enough to know what to do with a UUID can
probably be trusted with some conventional syntax.)


Gerry replies,
Most of the "ugly stuff" in the noodle is the result of the need to
interface with the truly ugly stuff we were faced with in Windows;
backward-compatibility stuff, if you will. It is not representative of what
we envision as pure Plain English code, or even Hybrid code. When we get
around to writing an operating system in Plain English, most of this ugly
middle layer will simply disappear.


Bartc says,
What's not clear is whether an expression such as A+B*C needs to be
written as 'Multiply B by C then Add A', or whatever it might be. See,
people who had known perfectly well how to write such an expression,
are now reduced to guessing! I think anyone who's been to school would
be able to cope with writing algebraic expressions. (I take it that
numeric constants are allowed to use digits and don't have to be
written out in words.)


Gerry replies,
We have two classes of people to consider here: the "learned" and the
"unlearned". The unlearned -- almost everyone, relatively speaking -- will
say that "Five plus five times three" equals thirty, not twenty. If you
doubt that statement, go down to Walmart and ask around. The learned class,
on the other hand, will often convert that statement to something like
"5+5*3" or even, "5+(5*3)" in their heads and arrive at the alternate value.
Both groups, we believe should be allowed to code what they're thinking, in
the syntax they're thinking it. Future versions of our compiler --
particularly the "hybrid" version -- will support that. No guessing
necessary, since the compiler will select the correct precedence rules based
on the syntactical form (eg, if the variables are named in an English-like
way with leading articles and there are no special symbols present, we'll
take it the Walmart way; if the statement has "mathematically inspired"
names without leading articles and if there are special symbols are present,
we'll take it the Oxford & Cambridge way; when in doubt, we'll ask for
clarification.


Bartc says,
So in many ways the language is conventional...


Gerry replies:
Sure; we're not interested in reinventing any wheels here. We're more
interested in "getting back to basics".


Bartc says,
...(apart from it's many
restrictions: no nested statements for example);


Gerry replies:
The restrictions we implemented were intended (1) to "force" the code into
more natural modes of expression -- people don't typically nest their IFs in
everyday speech, and especially not when they're trying to be clear; and (2)
to mimic the level of understanding that we might find in, say, a five-year
old child -- thinking that if we could get the computer to understand like
that, we'd really have something! Five-year-olds can properly execute all
kinds of commands, for example, yet they know nothing of real numbers, and
traditional mathematical precedence rules, etc. So how do they ever manage
to be so capable?


Bartc says,
...so what does plain
English add except long-windedness and clutter (and which can't be
done for viewing purposes by a translator or a smart editor)?


Gerry replies,
What Plain English adds is a "naturalness" to the coding process (plus
self-documenting code, a great syntax for beginners that can also be used to
later teach all sorts of other programming concepts and techniques, etc).
But the important thing is the "naturalness" of the process. This is most
evident with beginners, of course: a primary school child is obviously going
to have less trouble with "Clear the screen" or "Paint the screen black"
than something like "graphicslib.clrscr(0x000000)". But we found -- even
though we are experienced programmers in a wide variety of traditional
languages -- that after coding in Plain English for a while, we found Plain
English more natural to think about and more convenient to type (in spite of
it's "long-windedness"). I don't, however, think any experienced programmer
will be convinced of that until he actually tries it for a significant
period of time, with an open mind. "User-friendly is what the user is used
to". That's why we recommend that people actually print off the first 50
pages of our instruction manual and actually type in the sample program, a
little at a time, before jumping to any conclusions. Reading the code isn't
enough; you actually have to type it to get the "feel" of programming in
English.


Bartc says,
You're right that it is rare to use natural English as a basis for syntax,
but perhaps there are good reasons for that!


Gerry replies,
Perhaps. Perhaps not -- after all, it's what MOST people use MOST of the
time for MOST every kind of communication. Here we are, in fact, you and I,
doing it again. A natural language framework with snippets of alternative
syntax where appropriate.


John says,
Even COBOL has COMPUTE A=B+C+D as an alternative to
ADD B TO C TO D GIVING D (or something like that.)


Gerry replies:
Sure. See my answer to Bartc above.


John says,
English isn't a very good way to describe algorithms
once they get at all complicated.


Gerry replies:
Which is one of the greatest advantages of Plain English programming: it
encourages simplicity; it discourages algorithms that "get at all
complicated". As Einstein said, "If you can't explain it simply, you don't
understand it well enough." Plain English quickly "tips you off" to those
instances when your thinking is convoluted or unclear.

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