Re: Writing A Plain English Compiler

On 11/6/2014 6:52 PM, Gerry Rzeppa wrote:
> Gerry replies, Yes, I am assuming a particular, very specific way of
> looking at programming, because that's the model that we find works
> best for us.
  >
> Gerry replies, It is our belief that in many cases, parallelism of
> any kind is simply overkill.
  >
  > Gerry: We fully agree: that's the whole point of Hybrid programming;
  > you use the mode of expression that's most natural for each part of a
  > program. But the whole is contained in the most natural framework,
  > specifically, a natural language (in our case, English) -- like a
  > math book, or a physics book, or a technical (or non-technical)
  > paper. Think Plain English with sub-compilers for whatever other
  > syntaxes seem generally (or specifically!) useful.


I'm putting these three replies in juxtaposition with each other
because it's the best way I can think of to explain the inherent
contradiction I see.


You want to design a language model that allows people to express
their thoughts in the most natural way possible. Yet at the same time,
you limit the expressibility of the programming model because, well,
you personally don't think naturally in alternative models and thus
you don't see why other people might.


When I tried to point out examples of alternative paradigms, your
reply was fixated on trying to prove that you could express them in
your procedural paradigm. That's not the point. The point was that
having to do these paradigm translations is as much a programmer
burden as, say, having to translate from "I need to solve this
equation" to writing the code to solve that equation.






> Once it has slowed to one or two seconds between pops, take it out
> of the microwave.
>
[ ... ]
> Gerry replies: But we can express that thought, as above. Or like
> this:
> To make some popcorn: Put the popcorn into the microwave oven. Turn
> on the oven. Loop. If it not has slowed to one or two seconds between
> pops, repeat. Take the popcorn out of the microwave.


But those two statements are not semantically equivalent. The example
you give requires the program to continually check in a busy-wait
loop; the example I gave does not.


> Gerry: Actually, what we're most proud of is not the syntax per se,
> but (1) the fact that we were able to do so much with so little: that
> we were able to conveniently and efficiently write a complete,
> non-trivial and iconoclastic development environment with a unique
> native-code-generating compiler/linker for a subset of English (with
> a wysiwyg page-layout documentation facility, to boot) entirely in
> that very subset of English


After reading the thread you posted, it became clear to me that you
are (were?) under the impression that having a self-hosting compiler
was rare for a new proposed language. On the contrary, it is (to my
knowledge) standard rigor to present a new language by having its
self-hosted compiler be the largest application written in said
language. I've even heard it opined that this tends to cause people to
optimize their language design for writing compilers to the detriment
of other kinds of applications.


Your comments about "subset of English" are misleading, when taken in
context of your stated goal of making a "natural language" compiler.
That term, in the eyes of most, would imply that you could, say, build
a compiler that inputs the ISO C++11 specification and outputs a
working C++11 compiler.


Regardless of whether or not that is what you desire to build, your
prototype does not clearly make any advancements to that goal. What
you have is not a compiler that parses English but one that parses a
language which happens to be a subset of English--it's a very big
difference, but several others have attempted to explain that
difference to you and failed, and I have no expectation of being any
different.


> and (2) that our system can be used,
> educationally, with everyone from primary school children to college
> students writing compilers -- the very same development environment
> and language being suitable for both.


Programming came so naturally to me that I disclaim any ability to
properly evaluate programming 101. But the responses you have given,
both in this newsgroup and the AnandTech forum thread, suggest to me
that you are aware of the issues in writing large, complex software:
you appear to value minimalism in a language (rather than in client
code) very highly, and you appear to be very dismissive of "new"
paradigms.


A mild example of that tendency is present in the statement I quoted:
you list compilers as the "more complex" endpoint, yet compilers are
relatively simple affairs--which is why compiler courses tend to
assign "build a compiler" as an ongoing project in the course. The
sorts of projects I associate with production languages tend to start
considering themselves large only when they get a few million lines of
code.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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