Re: A Plain English Compiler

Martin Ward says, "Plain English" is even more verbose that COBOL...


Dan Rzeppa replies, Terseness wasn't the goal, writing in English was.


Martin Ward says, This means that multiplication does not take precidence
over addition in "Plain English" (unlike in mathematics).


Gerry Rzeppa replies: Plain English strives to be natural. Ask a few people
on the street what "five plus five times three" is: most (f not all) will
say, "Thirty," not, "twenty" as you suggest. Really. Try it.


Martin Ward says, "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.


Dan rzeppa replies: At the time we wrote the language there weren't a lot of
commodity 64-bit machines. Seeing how we've managed to implement 8-bit,
16-bit and 32-bit numbers, I'm pretty sure we could implement 64-bit ones
too.


Martin Ward says, I don't know what you do if you
want to address more than 4GB of RAM...


Dan Rzeppa replies, We'd implement the 64-bit numbers and away we'd go.


Martin Ward says, ...or, for that matter, work with
floating point numbers!


Dan Rzeppa replies, Don't need floating point numbers. The ratios work well
and, unlike floating-point numbers, can accurately represent one-third.


Gerry Rzeppa adds, And monetary amounts. We're not saying there aren't
particular applications that are well-served by floating point numbers.
We're simply saying that for our immediate purposes, they weren't (and
aren't) necessary. If we're trying to get the machine to understand English
at the level of, say, a three- to five-year-old, we hardly have to think
about floating point numbers.


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


Dan Rzeppa says, We were writing Plain English (not Plain Mandarin) and
didn't need any other characters than the standard ASCII set. Just like we
don't need Unicode to discuss these matters with you.


Gerry Rzeppa adds, And that's hardly the kind of complaint one should raise
regarding a proof-of-concept prototype that is focussed on entirely
different issues!


Martin Ward says, 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
me!


Gerry Rzeppa says, It appears you're missing the point again, Martin. In a
proof-of-concept prototype, one strives for simplicity --and especially so
in matters that are tangential to the line of research being pursued.


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


Gerry Rzeppa says, Actually, there is a standard power operation in Plain
English. But it didn't get much use within the scope of our investigations,
so it doesn't appear in the documentation.


Martin Ward says, Finally: there are no nested IF statements and no nested
loops.


Dan Rzeppa replies, Right on. Pretty amazing that one can conveniently and
efficiently write an entire development system -- desktop, file browser,
text editor, dumper, compiler, and page-layout facility -- without them,
yes?


Martin Ward asks, How do you process a two-dimensional array without a
nested loop?


Dan Rzeppa replies, Obviously, with two non-nested loops.


Gerry Rzeppa adds, There are many hierarchical structures in the bowels of
our Plain English development system that are several levels deep and are
processed in this way. Our page editor, for example, processes "shapes"
(text blocks, bitmapped-graphic images, vector-graphic drawings, etc) on
"pages" that are part of "reams" (collections of related pages). See below
for further remarks.


Martin Ward says, 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!


Gerry Rzeppa replies, Arrays (as a data structure native to Plain English)
are under investigation; they're not common in everyday speech which was our
main area of investigation. Our compiler does, however, employ a tentative
implementation of arrays in the "index" facility that is used by the
compiler for symbol tables, the page layout facility for spell-checking,
etc; but that facility is implemented entirely in a library, and is not
native to the compiler itself.


Martin Ward says, 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!


Dan Rzeppa replies, In such cases, shared data is typically passed as
parameters, not as global variables.


Gerry Rzeppa adds, And we think it's desirable to keep routines short. While
it may seem a nuisance to be "forced" to split one's routines up this way,
our consistent experience has been that in many (if not most) cases, the
additional routines have later come in handy and -- since the necessary
variables were passed as parameters -- could be called directly.

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