Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: =?UTF-8?Q?Joshua_Cranmer_=f0=9f=90=a7?= Newsgroups: comp.compilers Subject: Re: Writing A Plain English Compiler Date: Wed, 05 Nov 2014 00:54:18 -0600 Organization: A noiseless patient Spider Lines: 100 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-11-005@comp.compilers> References: <14-11-004@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: miucha.iecc.com 1415308358 81238 2001:470:1f07:1126:0:676f:7373:6970 (6 Nov 2014 21:12:38 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 6 Nov 2014 21:12:38 +0000 (UTC) Keywords: design Posted-Date: 06 Nov 2014 16:12:38 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1413 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