specifications (was Re: Languages: The Bigger the Uglier)

>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
--

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