RE: Language Design Principles, was C++ intermediate representation.

Quinn Tyler Jackson <quinn-j@shaw.ca> wrote in news:05-05-130
@comp.compilers:
> Tomorrow's better parsing technologies may not encourage tomorrow's
> better programming languages to be more parsable -- they may have the
> opposite effect. We may end up with programming languages with *more*
> ambiguity and more difficult constructions than today's most complex
> languages. As the tools increase in power and that power is proven
> safe, what those tools are used for, and what results from that
> increasingly sophisticated use may result in programming languages not
> unlike the confusing English found in this paragraph. 20 or 30 years
> down the road, we may look back on C++ and Perl and say, "Oh, for the
> days when programming languages were as easy to write grammars for as
> C++ and Perl."
>
> Pure speculation of course. But I hope it's the case, because it is my
> opinion that parsing theory and practice hasn't yet even touched the
> barest of surfaces of what is technically (or will be technically)
> feasible in the field, let alone have it declared a solved problem.


Excuse me for acting naive, but why do languages with such monstrous
constucts ever make it past the first or second peer review without
having the grammar simplified? Why do language designers so rarely
strive for a canonical set of productions? I guess I am implying that
language designers are as undisciplined a set of cowboys as exists in
computer science.


I am reminded of Wirth's famous quote: "A language that is simple to
parse for the compiler is also simple to parse for the human programmer,
and that can only be an asset."


A problem is that a coherent set of Language Design and Implementation
Principles has never been proposed or adopted (that I know of). Maybe
there is still time for a group such as comp.compilers to develop one and
keep foolish language designs in the future.


Let me propose one principle: A language should state explicit design
goals and minimal uniform syntax and semantics to implement the language
the goals specified. The design goals are vital; otherwise, there is no
basis to analyze the design and implementation for a particular
application domain.


Have fun!


Tom Reid
[Wirth made many pithy comments, some of which have held up better in
practice than others. It's often been noted that using a semicolon to
separate statements as in Algol and Pascal is elegant but error prone,
while using them to terminate statements as in PL/I and C is ugly but
matches the way we think. Or, for a particularly egregious example,
perl has its usability faults, but the difficulty of parsing it is
down in the noise. -John]

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