3 ms·

I do not agree that a spec has to be written in English. Like most natural languages, it is very easy to be ambiguous and to underspecify. Resolving this can ma

by arnarbi 14y ago

I do not agree that a spec has to be written in English. Like most natural languages, it is very easy to be ambiguous and to underspecify. Resolving this can make English just as human un-readable as anything else. Specs like this should be written as executable reference implementations in a well defined programming language. This can very well be human readable, and should be done without regard for efficient execution. It's less ambiguous, amenable to automated conformance testing, and is easier to evolve than a natural language document.

chc 14y ago
If that's the spec, how do we know which aspects of the executable are really part of the specification and which are implementation details? For (a somewhat extreme for the sake of illustration) example, if the spec is written for Ruby 1.8, do C implementations have to intentionally slow down to match its execution speed?
- Too 14y ago
  Use of well established standards. For example BNF or railroad diagrams can cover a majority of a language specificaton without using English.
  - chc 14y ago
    I think you're unintentionally moving the goalposts here. The idea I was questioning wasn't "Specs should be written in something other than English," it was "Specs should take the form of an executable reference implementation." AFAIK railroad diagrams are not executable. I'm also not sure how BNF is supposed to specify things like "the map function applies a function passed in to each argument in a list".
- arnarbi 14y ago
  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.
  - chc 14y ago
    > 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.
    - arnarbi 14y ago
      > 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.
blasdel 14y ago
IETF standards are required to have multiple interoperable implementations of the usually post-hoc english language spec. One implementation can never be enough.

by arnarbi 14y ago

chc 14y ago

If that's the spec, how do we know which aspects of the executable are really part of the specification and which are implementation details? For (a somewhat extreme for the sake of illustration) example, if the spec is written for Ruby 1.8, do C implementations have to intentionally slow down to match its execution speed?

Too 14y ago
Use of well established standards. For example BNF or railroad diagrams can cover a majority of a language specificaton without using English.
- chc 14y ago
  I think you're unintentionally moving the goalposts here. The idea I was questioning wasn't "Specs should be written in something other than English," it was "Specs should take the form of an executable reference implementation." AFAIK railroad diagrams are not executable. I'm also not sure how BNF is supposed to specify things like "the map function applies a function passed in to each argument in a list".
arnarbi 14y ago
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.
- chc 14y ago
  > 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.
  - arnarbi 14y ago
    > 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.

blasdel 14y ago

IETF standards are required to have multiple interoperable implementations of the usually post-hoc english language spec. One implementation can never be enough.