Subject: Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C)
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Feb 27 1996
Keywords: standards
Newsgroups: comp.compilers

jgm@CS.Cornell.EDU (Gregory Morrisett) writes:

> Providing a precise semantics for a language is not just something
> for the "theoriticians" to do -- it really provides the basis for a
> language -- a contract for both the implementors and the users...

Unfortunately, such contracts work much better if they are written in
a language that the implementors and the users can understand without
calling in a specialist to interpret for them.  This is why the ANSI C
committee deliberately decided against formal specifications.  The
fact that much of the audience for the contract cannot read formal
specs is regrettable, but it is a fact and it will not change any time
soon.

In the real world, contracts are not written in Esperanto, despite the
theoretical advantages of doing so.
--
Henry Spencer, henry@zoo.toronto.edu

Subject: Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C)
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Mar 01 1996
Keywords: standards, C
Newsgroups: comp.compilers

>> ...This is why the ANSI C committee deliberately decided against formal
>> specifications.  The fact that much of the audience for the contract
>> cannot read formal specs is regrettable, but it is a fact and it
>> will not change any time soon.

blume@zayin.cs.princeton.edu (Matthias Blume) writes:
>It is also a fact that the same audience is unable to understand the
>ANSI C specification...

Actually, *most* of them can understand *most* of it quite well.  Fine
points can require consulting a language expert, but that's true of
any form of language description; there is no way around the fact that
such specs are substantial documents and some questions require
knowing the whole spec intimately.  However, there is a large payoff
for even limited understanding: not only does it make it possible for
non-experts to answer simple questions themselves (*usually*
correctly), it also makes it easier for them to gradually deepen their
understanding until they stop needing experts.

In this and similar matters, there is a school of thought which claims
that only experts should get involved, that if you aren't up to being
an expert, you should consult one rather than trying to solve your
problem yourself.  While there is some merit in this view, it also
ignores reality: experts are in short supply, and many people need to
get results without having the time to become experts or the money to
consult existing experts, even if this does mean some risk of
mistakes.

Languages whose definitions are accessible only to experts are likely
to remain the obscure playthings of tiny communities of experts.

>...I venture to say that everybody who can read and FULLY
>understand all of the definition of ANSI C will also be able to
>understand "The Definition of Standard ML", (perhaps after a short
>introduction to the notation used...

Quite possibly true.  However, such people are a small minority of
those who can read, and benefit from reading, the ANSI C definition.
--
Henry Spencer, henry@zoo.toronto.edu

Subject: specifications (was Re: Languages: The Bigger the Uglier)
From: Henry Spencer <henry@zoo.toronto.edu>
Date: Mar 01 1996
Keywords: standards
Newsgroups: comp.compilers

>Unfortunately, such contracts work much better if they are written in
>a language that the implementors and the users can understand without
>calling in a specialist to interpret for them...

jgm@CS.Cornell.EDU (Gregory Morrisett) writes:
>Well, I hate to tell you, but contracts are written in "legal-ese" and
>specialists (aka Lawyers) are called in to draw them up and interpret
>them.  :-)

Actually, in recent years there has been a definite trend away from
the more extreme legalese.  This is partly because the courts have
shown some tendency to say that people are not expected to conform to
all the details of an agreement they don't understand.  (I know of one
software company which simplified its licensing agreement radically
for exactly that reason.)

One should distinguish between drawing up contracts and interpreting
them.  Drawing up contracts -- be it in law or in programming
languages -- almost always calls for a specialist, because you want to
be sure that nothing important has been left out and that there are no
hidden defects.  That calls for extensive background knowledge and
experienced judgement.

However, it is still reasonable to ask that the resulting document be
intelligible enough -- without an interpreter -- that simple questions
can be answered without specialist assistance.  (Complex questions
usually need specialist help either way.)

> I'm not discounting that a formal spec should be easily understood
> by both implementors and users, nor am I discounting the idea that a
> separate user's guide is needed for a language, with illuminating
> examples, and lists of potential pitfalls.

Actually, in some ways the separate user's guide is a confession of
failure -- it says "you're not expected to understand the real spec,
so here's a watered-down version".  This causes problems when the two
documents disagree.  (And inevitably they do.)

> ...Don't you readily accept the idea of presenting the syntax of a
> language using a BNF grammar (or perhaps even an LALR(k) grammar)?
> Then why protest a formal definition of the semantics, using, say
> structured operational semantics?

Because most people in this business have been exposed to BNF or the
equivalent, and find it easy to understand, and neither of these
statements is true of structured operational semantics.  This isn't
irrational prejudice; if the formal-semantics methods were as simple
and clear and readable as BNF, they would have been adopted as quickly
and enthusiastically as BNF was.  They haven't been.

It is not hard to see why the difference exists: semantics is a harder
problem, and demands more complex tools.  That still doesn't change
the fact that only a tiny minority of potential spec readers are
comfortable with those tools.  Wishing won't change that.

The major reason why C rose to its current position of importance,
despite lack of early support from any influential supplier and loud
retching noises from the language-design community, was that it gave
users what they wanted, instead of telling them they shouldn't want
that.  Users want specifications they can read.
--
Henry Spencer, henry@zoo.toronto.edu