alt Hacker NewsYeah that’s what I mean by strictly. Does your implementation take shortcuts or does it hold itself to a higher standard and not do that? Does it only use available memory as the ultimate limit?
A lot of specs contain these optional limitations. The C standard allowed implementations to truncate variable names to 31 characters if they have external linkage and 63 if internal linkage. Would you be happy if your implementation actually does that? Of course not. Neither LLVM nor GCC does that. That’s because people writing compilers also hold themselves to a higher standard. Now imagine this kind of attitude being pervasive.
Replies
I don't get your argument here. You say Haskell conforms strictly to the spec and that's a good thing, okay. But then if the C spec allows for truncated names, a compiler could strictly follow the spec and truncate names. So strictly following the spec is not in fact the whole story
Which C standard? ANSI C? C99?
The thing is this goes both ways. For example, JSON with duplicate keys is valid JSON, and the standard specifies two ways to handle them. To support all ways JSON is used, an implementation will have to provide for both ways, and decide which one to pick as the default. The stricter default on the parsing side is at the same time the less interoperable one. Same for numeric precision: seamlessly allowing higher precision on the generating side lowers interoperability towards the receiver (but lessens demands on the driving application), while accepting it on the parsing side increases interoperability (but also places higher demands on the consuming application). So what do you do? There is no easy and simple answer, unless you want to limit the scope of applicability of your implementation.