Two questions were recently asked:

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?


2 Answers 2


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.

  • $\begingroup$ Regarding the "+" question, could you elaborate on why you think it is "obviously on-topic"? I don't see how it is about either designing or implementing a language, it is about how to use a language to do something. $\endgroup$
    – kaya3
    Commented Nov 26, 2023 at 22:54
  • 6
    $\begingroup$ @kaya3 I think “does currying inevitably have to bottom out into calling uncurried operations?” is obviously about an implementation aspect of a programming language. $\endgroup$
    – Alexis King Mod
    Commented Nov 26, 2023 at 23:05
  • 1
    $\begingroup$ "the OP has taken a rather combative stance in comments and in chat" - in defence of the OP, I'm also accustomed to receiving (not here, elsewhere) the behaviour which has triggered him, difficult to fully characterise in a sentence, but commonly associated with a denigration of "philosophy" associated with a subject, which provokes arrogant or awkward behaviours whenever they suspect a question to be in that category. $\endgroup$
    – Steve
    Commented Nov 27, 2023 at 15:00

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.)

  • $\begingroup$ I appreciate that you understood that the current close-practice is destructive, that you feel guilty of being destructive which made it necessary for you to explain your motivation. This illustrates nicely the failure of the close-system. This is the very first time, I got an detailed explanation for a close. Probably nobody else gets this. Instead, they just get the door slammed right in their face. $\endgroup$
    – ceving
    Commented Nov 26, 2023 at 14:31
  • 2
    $\begingroup$ @ceving Please don't put words in my mouth. I have said neither of the things you attributed to me, nor are either implied by anything I've written. As explained in the question here, the purpose of this Q&A is to discuss what we think the scope of the site is, since it appears there is disagreement about that. Also, this is not the first time you got an explanation of why I voted to close your question, since I already explained the reason for that in the comments on your question. $\endgroup$
    – kaya3
    Commented Nov 26, 2023 at 16:07
  • 1
    $\begingroup$ "it seems to be a philosophical question that doesn't matter for language design or implementation" - what exactly is the "philosophy" here, as distinct from "language design and implementation"? $\endgroup$
    – Steve
    Commented Nov 26, 2023 at 17:26
  • 1
    $\begingroup$ @Steve The comments and answers descended into a philosophical debate over whether Church numerals really represent arithmetic, whether functions in lambda calculus can really represent binary operators, whether certain things are "cheating" or not, whether using a lookup table counts as "computing", etc. $\endgroup$
    – kaya3
    Commented Nov 26, 2023 at 17:40
  • 2
    $\begingroup$ @kaya3, the OP asked "how to implement a 2-ary function like the addition in a language having only 1-ary functions". How is that not a question about "language design or implementation"? It is in the form of "how to implement X in a language having design feature Y". It takes some mental gymnastics to argue that this question in fact concerns neither language design nor implementation. $\endgroup$
    – Steve
    Commented Nov 26, 2023 at 17:56
  • 1
    $\begingroup$ @Steve Implementing addition in a programming language is not the same as implementing a programming language. Why do you ask me something which I have just answered at length? If you disagree with my answer then write your own answer. $\endgroup$
    – kaya3
    Commented Nov 26, 2023 at 18:58
  • 3
    $\begingroup$ Regarding the "+" question, I felt like there was also clearly a philosophical question (which I found spurious) about what it means for an operator to be unary. Clearly an operator that means "add 5 to the operand" is just as "unary" as "increment", because "increment" means precisely "add 1 to the operand", and the numbers 1 and 5 are not particularly special. For that matter, negation is more or less equivalent to multiplication by -1 - again, the -1 should not be thought of as an operand. $\endgroup$ Commented Nov 26, 2023 at 20:38
  • $\begingroup$ More philosophy here, but isn't one meant to be the unit, at least mathematically? It's a standard, and increment is typically thought of as unary. And indeed, if 5 is predefined (a la lambda calculus), shouldn't "add 5" be unary as well? $\endgroup$
    – Someone
    Commented Nov 28, 2023 at 22:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .