Re: Writing A Plain English Compiler

On 11/4/2014 3:50 PM, Gerry Rzeppa wrote:
> Having worked with a wide variety of traditional languages, and having
> written a number of compilers together, we knew that a practical procedural
> programming language could be concocted with just five types of statements:
>
> 1. Type definitions;
> 2. Global Variable definitions;
> 3. Routine Headers;
> 4. Conditional Commands; and
> 5. Unconditional Commands.


Honestly (and I mean no disrespect), this doesn't feel like "practical
procedural programming language" but "C or maybe Java." Personally,
I've never felt that distinguishing between procedural, imperative,
object-oriented, functional, etc. is terribly useful because the major
modern languages end up being a complex mismatch of everything. I mean
C++ and Java both now have lambdas, and C++ is even talking about
coroutines the other day.


Essentially, I find your categorization troubling because you're
assuming a particular, very specific way of looking at
programming--and a model that's not necessarily reflective of most
large-scale programs (where object-oriented code rules the day).


A good example of where things really break down is in the
introduction of parallelism. Many (all?) languages these days have put
some emphasis on trying to decide good parallelism and concurrency
models at increasingly fundamental positions in the language. I
believe there's a widespread consensus that shared multithreading
isn't good enough, but while there are models of more structured
constructs (e.g., OpenMP, which does explict task parallelism), I
can't speak to how often those get used in practice in major systems.
Certainly, I think the academic community heavily desires the use of
"structured" parallelism instead of "unstructured" (much as we prefer
structured control flow over the goto statement), but industry best
practices can lag a bit or a lot.


> The result of these ruminations was the following tentative definitions for
> our language:


What you have done is not used English as a programming language. What
you did was start with a semantic definition of your language and work
out a syntax for it that happens to be a subset of the English
language. Clearly, anything that's not expressible in your semantic
language definition isn't expressible in the English-language-version
of your syntax--even if that thought is expressible as a reasonable,
simple English sentence. Since there's a bit of a cooking theme in the
examples, here's an example of such a sentence from a cooking article
in a recent newspaper:


Once it has slowed to one or two seconds between pops, take it out of
the microwave.


In other words, now you have an example of event-driven programming!
Well, kind of (there are better example sentences). The way you've
defined your language, though, you can't express this. And it could be
that you don't want to--that's a design decision, and design decisions
are basically subjective opinions.


The reason I bring this all up, though, is that you make a conceit in
your Indiegogo page that the importance of what you're doing is that
you want "scientists, engineers, programmers and many others [ ... ]
to simply write down what they're thinking, in the way that's most
natural." And the way that's most natural is not necessarily
procedural programming--sometimes you can express stuff most naturally
in an event-driven model, perhaps a functional model, or maybe an
actor model. And that's why the major programming languages of today
are all multi-paradigm languages (and even continually expanding their
paradigms)--because, in the end, sometimes it's better to structure
portions of a program in different paradigms.


Now, to some degree, a Turing-complete language can emulate any other
Turing-complete language, even if the two are completely different,
incompatible paradigms. That doesn't mean it's a wise idea though, and
you can lose a lot of expressiveness and simplicity in such a
conversion. Using a parser generator like bison allows for you to much
more clearly use the code as documentation for the syntax of the
language--writing the code in a recursive-descent parser loses that
clarity, and it requires substantial commenting to recover what is
going on. You can also use the more abstract description to gain more
features: e.g., a LALR parser basically boils down to


for (each token):
      switch (token):
            ... all code inline here ...


-- and that form is easier to convert into one that gets its tokens
streaming than a recursive descent parser. (On the other hand, parser
generators tend to suffer in their ability to print good diagnostics.)


TO sum it up, from my perspective, you have a rather banal and
underwhelming language, semantically speaking (actually some of the
semantic decisions you make some of us mightily disagree with, but
those are quibbles compared to what I discussed in this post). The
syntax seems to be what you are most proud of, but I rather suspect
that most of the people in this group don't care too much about
syntax.
--
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.