Re: [tlug] linux@example.com How many widely can we do that?

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2009-10-28 13:13 +0900 (Wed), Stephen J. Turnbull wrote:

 > > In many cases the .h is easier to read [than the generated docs]
 > > (assuming you can program in C, which almost goes without saying
 > > in this context).
 > 
 > Oh, well if that's the case, they ought just to declare the .h files the
 > documentation.

Indeed, that was my whole point (at first, but I have some other bones
to pick now :-).

 > I suspect even you would prefer to put a BNF into a parser generator
 > than attempt to write a C program that does what the BNF specifies.

Of course.  I don't have an objection to formal specifications.  But
note that to the extent that a BNF is "executable code", the output is
boolean! ie, "parse succeeded" vs. "parse error".  yacc input is
something else; I would object to calling that a (good form of)
specification.

 > > But what's really bad about it is that if changing the .h
 > > automatically updates the documentation, the developer of client code
 > > is completely hung out to dry.  There is nothing left that can be
 > > considered an independent specification of the behavior.
 > 
 > Right, which is a good thing, IMHO. Code is, de facto, a specification.
 > If you have an independent specification, now you have two
 > specifications, which is very much like having two clocks.

Yikes!  If the code is *the* (not *a*) specification, as soon as you
make a change you have two specifications: the pre-change spec, and
the post-change spec.  Make another change, and you have either three
or four specs (depending on whether you think of the changes as a
linear branch, or as two patches that can be mixed and matched).

 > > Even backward compatibility can be immediately disposed of as "we
 > > changed unspecified behavior, you really shouldn't be depending on
 > > that!" because *everything* is unspecified.
 > 
 > Well, only if you refuse to admit that your code is also a spec.

Of course I admit it is *a* spec.  There is a place for reference
implementations.  The problem is that if you have 1,000 revisions in
your repo, you have 1,000 specs (or maybe a *lot* more if you consider
the implied combinatorics of the patches).  Don't you think that is
too many specs?