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

Author

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

Tom

2005-05-16, 4:00 pm

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]

Nick Maclaren

2005-05-16, 8:59 pm

Tom <rabbit@thehole.com> writes:

|> 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."
|>
|> [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]

Correct. One of my mental designs includes some useful language
features which are easily parsable by computers but a nightmare for
humans. Consider a statement-based language, where the syntax is
defined by a set of regular expressions and you can extend it by
adding your own (subject to a few orthogonality and precedence rules).
I don't mean SOME of the syntax - I mean ALL of the syntax. Yes, LISP
was there first :-)

'Twouldn't be hard to do with a recursive descent parser and lexical
analyser - integers with the digits backwards (but only in some
contexts) and pseudo functions that deliver syntactic separators
depending on the values of a (run-time) argument are merely two of the
more obvious, er, uses. You can, of course, do something similar to
the second with the C preprocessor.

Regards,
Nick Maclaren.

Rodney M. Bates

2005-05-18, 4:02 am

Nick Maclaren wrote:
> Tom <rabbit@thehole.com> writes:
>
> |> 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."
> |>
> |> [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]
>
> Correct. One of my mental designs includes some useful language
> features which are easily parsable by computers but a nightmare for
> humans. Consider a statement-based language, where the syntax is
> defined by a set of regular expressions and you can extend it by
> adding your own (subject to a few orthogonality and precedence rules).
> I don't mean SOME of the syntax - I mean ALL of the syntax. Yes, LISP
> was there first :-)
>
> 'Twouldn't be hard to do with a recursive descent parser and lexical
> analyser - integers with the digits backwards (but only in some
> contexts) and pseudo functions that deliver syntactic separators
> depending on the values of a (run-time) argument are merely two of the
> more obvious, er, uses. You can, of course, do something similar to
> the second with the C preprocessor.

I think I understand that you are rebutting Wirth's statement that
easy to compile is easy for humans, by counterexample. But what are
you arguing then? That easy to compile is irrelevant to
comprehension? Counterproductive to comprehension? Just an
interesting mental exercise?

As a formal proposition, Wirth's statement is clearly not universally
true. But it is inconceivable to me that easy to compile is not
highly correlated to human comprehension, looking at the real
programming languages we use and leaving out carefully constructed
counterexamples.

The correlation is also not that high if you are satisfied with
programmers' having only anecdotal understanding of their language,
i.e. they seldom venture outside a mental list of standard code
fragments of known meaning that they have seen before. Unfortunately,
my experience is that the majority of programmers, both students and
practitioners, have only such anecdotal understanding and have great
difficulty generalizing to new combinations of constructs. I
attribute this in no small part to languages whose "system" is highly
convoluted or unsystematic.

It also my experience that those who do have a complete understanding
of a

language usually develop it only after extensive past
experience with a more simply-designed language.
[I dunno. My first language was Fortran, on punch cards, and it doesn't
seem to have damaged my comprehension too badly. -John]

Nick Maclaren

2005-05-18, 4:02 pm

Rodney M. Bates <rbates@southwind.net> wrote:
>Nick Maclaren wrote:
>
>I think I understand that you are rebutting Wirth's statement that
>easy to compile is easy for humans, by counterexample. But what are
>you arguing then? That easy to compile is irrelevant to
>comprehension? Counterproductive to comprehension? Just an
>interesting mental exercise?

Would you believe that I was simply rebutting Wirth's statement, and
not doing anything more? Well, I was :-)

However, I will give you a correct formulation of Wirth's statement:

A language that is hard to parse for the compiler is also hard
to parse for the human expert trying to decide if something is a
bug in the code or the compiler, and that can only be a problem.

However, as any logician knows, ~A => ~B does not imply A => B. While
I agree with Wirth in the desirability of simplicity in parsing, his
aphorism is factually incorrect.

Regards,
Nick Maclaren.

Rodney M. Bates

2005-05-20, 4:03 am

Rodney M. Bates wrote:
> It also my experience that those who do have a complete understanding
> of a

language usually develop it only after extensive past
> experience with a more simply-designed language.
And our moderator responded:
> [I dunno. My first language was Fortran, on punch cards, and it doesn't
> seem to have damaged my comprehension too badly. -John]

That was my first one too, but I attribute most of my comprehension to
languages after Fortran, but still learned in the past.
[Well, my second language was Trac. That doubtless warped me for
life. But its syntax sure is consistent. -John]

Dick Weaver

2005-05-20, 4:03 am

Rodney M. Bates wrote:
>
>... But it is inconceivable to me that easy to compile is not
> highly correlated to human comprehension, looking at the real
> programming languages we use and leaving out carefully constructed
> counterexamples.

There are two "comprehensions" involved with a programming language:
comprehending what the machine is being instructed to do and
comprehending the algorithm(s) implemented with a program.

For the easiest to compile languages, called "Assemblers", what the
machine is instructed to do is easy to comprehend while the algorithms
implemented are often the most difficult to comprehend (compared to
other languages).

Considering only algorithm comprehension, the correlation is high and
negative; simple non-problem specific languages (easy to compile)
often make algorithm comprehension hard, complex problem specific
languages (hard to compile) often, in their field of application, make
algorithm comprehension easy. Should it be otherwise, such
problem-specific languages would be judged failures.

dick w

Sponsored Links