1
\$\begingroup\$

The current meta consensus is that the implementation defines the language. The cannonical answer is: What's the policy on interpreter bugs?

I think this is too rigid: I think that a specification should also be able to define a language, if and only if the specification is sufficiently rigorous to uniquely define the behavior of a given program, and sufficiently clear that essentially anybody reading it would come to the same conclusion.

For example, consider this question: Old Languages with new implementations

A user would like to use a cellular automaton that was defined 17 years previously. A cellular automaton is a very well specified kind of language, where every possible detail has been specified in advance. The specification allows one to know exactly how the program should develop in any possible initial condition.

Other specifications that are similarly precise include the definition of a Turing machine, various grammars, some assembly language specifications, the BrainFuck specification, and so forth.

Less precise specifications, such as those accompanying most general purpose programming languages, would not define a language, since it's not clear how a given piece of code may function.

I prefer the system outlined above because I think our current rule strays into "That's the rule because we said so" territory. I think the system outlined above avoids the problems associated with accepting specifications too lightly, while allowing them to be used in appropriate circumstances.

\$\endgroup\$
6
  • 5
    \$\begingroup\$ Are you playing devil's advocate here or are you genuinely unaware that BF is one of the best arguments for the implementation defining the language, because the "spec" doesn't specify the datatype of the cell, the number of cells, wrapping behaviour, ...? \$\endgroup\$
    – Peter Taylor
    Jun 8, 2017 at 11:23
  • 2
    \$\begingroup\$ I'm not sure that there's a way to draw a line in the sand that would allow precise specifications but also disallow vague specifications. The only solution I can think of would be to allow languages who have a strict mathematical definition (like CAs), but then an interpreter still needs to be made, and that interpreter would then be subject to our usual rules. \$\endgroup\$
    – user45941
    Jun 8, 2017 at 11:25
  • \$\begingroup\$ @PeterTaylor I was unaware of those issues. The specification I've seen (0-255 cells, infinite in both directions) was pretty clear, but I could definitely imagine much worse specifications. \$\endgroup\$
    – isaacg
    Jun 8, 2017 at 13:04
  • 2
    \$\begingroup\$ @Mego The relevance of the difference comes when there are no interpreters which precede the question, or which implement the spec correctly and precede the question. \$\endgroup\$
    – isaacg
    Jun 8, 2017 at 13:05
  • 2
    \$\begingroup\$ 0-255 cells, infinite in both directions still leaves a few holes. What happens if you increment 255 or decrement 0? What does , do on EOF? Is input read in the form of bytes or integers? My point is that a seemingly clear spec can have a bunch of holes (undefined behavior) you might never know about until you write an interpreter. And if you miss them even when implementing the language, since the implementation is the language per our current rules, the interpreter simply does what it does; nothing is left undefined. \$\endgroup\$
    – Dennis
    Jun 8, 2017 at 13:49
  • 1
    \$\begingroup\$ Given the difficulty in specifying the brainfuck language, which is a very simple Turing tarpit, I don't think a complete specification (meaning nothing left implementation-defined) is reasonable or even possible, except possibly for the simplest, most uninteresting languages (like HQ9+). I really don't see a benefit in allowing specifications to define languages, but I see a lot of detriments. \$\endgroup\$
    – user45941
    Jun 8, 2017 at 15:57

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .