Those "+" and "C" questions, and this site's scope

Question

Two questions were recently asked:

• How to implement + in a language where functions accept only one argument?
• Why does Rust depend on C?

Both were closed and the latter was reopened, all three actions requiring the votes of five users. Michael Homer noted in the chat room that:

I think the + question is clearly on-topic and well-scoped, despite descending into low-grade arguments in the comments, and the original version of the Rust C question clearly was not, but they have almost the exact same respective close/reopen voters, so this may highlight a scoping conflict that we should consider documenting or resolving

Emphasis mine ─ the issue is that mostly the same people who voted to close the first question voted to reopen the second. So perhaps there are separate groups of users here who have different ideas about what questions are or should be on-topic or off-topic.

I think this is easier to discuss on Meta than in chat. Why should or shouldn't each of these questions be considered on-topic here?

Answer 1

For what it’s worth, I think it is a little bit unhelpful to have a single meta discussion about both of these questions. They seem rather unrelated (except for the fact that many of the close voters were the same). I did not vote to close either of these question (nor did I vote to reopen them), but I can offer my opinions.

The C question

As I said at the start of my answer, I think the question borders on being off-topic. In an ideal world, I think the right thing to do for questions like these is to close them and have a dialogue with the OP to better understand what they’re really asking, then edit the question to be on-topic if possible and reopen it. In reality, this strategy often does not work well, for two reasons:

1. If the question is not closed rapidly, users often post answers to the question as originally written. There is no generally agreed-upon mechanism for what to do with these answers if the question is substantially edited to be on-topic and reopened. In many cases, it is simpler to simply request that the OP ask a new question.

2. Having the dialogue with the OP in this first place can be challenging. The only mechanism for doing this is comments or chat, and plenty of users are responsive to neither. Even when they are, plenty of users are frustrated by the closure of their question and interpret the closure as a personal attack (or at least an expression that they have somehow asked a “bad question”), which is not really the intent, but it’s still something we have to worry about.

Fortunately, in this question’s case, I think the answer posted before the question was substantially edited is not wildly off the mark. I do think that much of it is dedicated to answering the off-topic portions of the question, but it’s not terribly egregious, so I don’t see any reason to take further moderation action. I would prefer that my answer be higher-voted, of course, but I am biased. :)

The + question

I think this question is obviously on-topic, though I do think that it would be improved by clarifying what precisely the question is. Since it is currently closed as “needs details or clarity”, I think that moderation action is not unreasonable, even if I probably wouldn’t vote to close it myself.

I do think that the question has generated a somewhat astonishing volume of discussion, which is not inherently a bad thing, but I do consider it to be at least a little suspicious. Moreover, the OP has taken a rather combative stance in comments and in chat, which certainly does not make me more inclined to feel sympathetic. For example, in a (now deleted) comment on the question, they wrote

It must be said that until SO does something about it, unconstructive people use the Close function to satisfy their destructive tendencies.

which is rather unhelpful and potentially exhibits the “closure is a personal attack” mentality I mentioned above. In a comment on one of the answers, they wrote

Maybe you can remove the Haskell code and replace it with words? Haskell helps only people who speak Haskell. For most of the other it is as useful as an answer in Latin.

which, intended or not, comes across as quite spiteful to me. On a site about programming languages, it must be expected that relevant programming languages will be discussed in answers, regardless of OP’s knowledge of them, and Haskell is unambiguously relevant to a question about currying. It is reasonable for users to request that some additional explanation be given, but it would be helpful to identify more precisely which parts are not understood and to show a baseline level of research effort to understand what has been presented.

It is always worth reminding people that everyone who answers questions on any Stack Exchange website does it as a volunteer, on their own time. A little grace goes a long way.

Putting that matter aside, I think the question has received a number of decent answers, and as far as I can tell, they answer the question as-written. However, OP seems to be of the opinion that the answers do not answer their question, or at least they seem to be uncertain, which supports the idea that the question is insufficiently clear. If OP feels otherwise, they are always free to clarify that either they do think their question has been correctly interpreted or how they think it has been misinterpreted, and we can take action appropriately. Without either of those things, though, I don’t see any reason to take further action.

Answer 2

I voted to close the "+" question and to reopen the "C" question. Here are my reasons (reposted from chat and expanded-upon).

The "C" question

To be honest, I don't see the problem with this question. Alexis King's answer clearly answers something on-topic, and as far as I can tell, the on-topic question it answers is the one that was asked.

That is, I thought the answer was good, and it was an answer to what I thought the question was about (i.e. I thought it was a question about the langdev aspect). The question has since been edited making it clearer (and much shorter, which is also a significant improvement!), but from my perspective if the improved version is on-topic then so was the original, because they're the same topic.

Michael Homer did also comment that perhaps the original version should have been closed as "needs more focus" instead of "off-topic". Since the present discussion is just about what should count as on-topic, I don't think we need to debate whether the original version needed more focus; the edited version is totally fine on that front, anyway.

The "+" question

The reason I voted to close this question is because it seems to be a philosophical question that doesn't matter for language design or implementation. In practice you implement "+" using the "+" operator from the host language (in an interpreter) or the target language (in a compiler), and the host or target language is assumed to have such an operator. If the question is about a self-hosting interpreter then it's still not a problem: you implement the "+" operator meta-circularly.

So if that's really what the question is about, then it's trivial, and the part about unary functions is a red herring. The OP would need to explain why they think having only unary functions might prevent a curried "plus" function in the standard library having a native implementation. (As noted by a commenter, Haskell has unary functions and a native "+", so there is no such barrier.)

So to me the question seems to be more like this: "Suppose you have a language which has only unary functions and no "+" operator. How would you implement an addition function in this language?" That's a question about how to use a (hypothetical) language, because it asks how to write some function in that language. I suppose it could be seen as a language implementation question if the goal is to use that hypothetical language to write an interpreter for some other language which needs a "+" operator, but I think that's tenuous, and there are so many other reasons "+" is useful that I don't think the problem is specifically-enough about writing interpreters. (The question doesn't even mention interpreters specifically, and it wouldn't matter for writing a compiler because "+" would still exist in the target language.)