Of course not. Such a spec would state what are its inputs and outputs, either as natural language descriptions or as types (say, if the reference language supports it).
Everything outside that (e.g. timing) would be fair game to optimize. Moreover, as I hinted at, a spec should not be optimized for speed or efficiency, but rather readability and unambiguity.
> Of course not. Such a spec would state what are its inputs and outputs, either as natural language descriptions or as types (say, if the reference language supports it).
So you agree it wouldn't work for specs to be "written as executable reference implementations in a well defined programming language"?
> Everything outside that (e.g. timing) would be fair game to optimize.
But sometimes you want to specify performance characteristics.
The simple fact is that without just embedding a traditional spec within it, an implementation cannot tell you what aspects of its behavior are "specified" and which are just implementation details. This makes reference implementations inadequate specifications. That's all I was getting at.
> So you agree it wouldn't work for specs to be "written as executable reference implementations in a well defined programming language"?
No, then I would be disagreeing with myself. :)
> But sometimes you want to specify performance characteristics.
For a Markdown processor, hardly. But...
> ... cannot tell you what aspects of its behavior are "specified" and which are just implementation details.
That is a fair point indeed. I was merely disagreeing with the linked article in that a spec should be in a natural language, which I still hold to. Such specs generally have problems with under specifying, leaving too much up to implementation, which often ends with a few main implementations sort of becoming the actual practical spec. Look at browsers over the history for many examples. Your point seems to be that reference implementations might overspecify instead. This is true, but is easier to compensate for IMO. For example with clear types, natural language parts or even by conformance test suites being part of the specification.
Everything outside that (e.g. timing) would be fair game to optimize. Moreover, as I hinted at, a spec should not be optimized for speed or efficiency, but rather readability and unambiguity.