Do we really need the [regex-golf] tag?

Question

I've been using search to find questions that don't have a tag for a winning criterion (https://codegolf.meta.stackexchange.com/a/908/3808), and here's the search query I have so far:

https://codegolf.stackexchange.com/search?q=%22%22+is%3Aquestion+closed%3Ano+-%5Bcode-golf%5D+-%5Bcode-challenge%5D+-%5Bpopularity-contest%5D+-%5Bfastest-code%5D+-%5Bcode-trolling%5D+-%5Bcode-bowling%5D+-%5Brosetta-stone%5D+-%5Bbusy-beaver%5D+-%5Bking-of-the-hill%5D+-%5Batomic-code-golf%5D+-%5Bcode-shuffleboard%5D+-%5Bcode-tournament%5D

I know, quite large. Anyway, of the 95 posts that it finds, I've noticed that some are tagged regular-expression and some are tagged regex-golf, and it seems to be pretty inconsistent. Some of them are even tagged with both!

So, my question is: do we really need regex-golf? Can't it just be merged or synonymized with regular-expression (and then maybe also tagged with code-golf)?

---

Edit: based on the answer, regex-golf probably shouldn't be a tag. This is now an explicit synonym request: could regex-golf become a synonym of regular-expression?

Answer 1

We had this today with a regex golf question.

I agree with the previous answer that regex-golf is superfluous and such questions should be tagged code-golf and regular-expression.

However, I do not agree with the conclusion being that regex-golf and regular-expression are synonyms. For one thing, there could be regular-expression challenge that are not code-golf, but since regular-expression is the parent tag of the two, that maybe isn't a problem semantically.

However, it's a problem practically. At least 3 users (including myself) tried to edit the above question today, by removing code-golf and adding regex-golf, because the latter still shows up in the auto-complete list. There is no indication though that this is a synonym for regular-expression. So while you're editing, you see them both and think "Nice, I tagged this more appropriately" (seeing we can't expect everyone to be aware of this here meta question) - but when you submit, your regex-golf tag suddenly vanishes, and the challenge is left without a winning criterion.

Even if it's just to avoid such edit frenzies in the future, I suggest to

• remove the synonym relationship
• untag/retag the two challenges that are still regex-golf
• edit the regex-golf tag wiki to read "This tag is deprecated, use code-golf and regular-expression instead."

Answer 2

We do have some challenges correctly tagged with regular-expression+code-golf that don't count as regex-golf in the sense described in the tag wiki:

"Regex golf is a programming challenge involving two lists of items. The goal is to create a regex that matches one list without matching anything in the second."

Some past challenges that are code golf and do involve regexps, but don't fall under the definition above (even in a loose sense), include:

• Negative Regexp:

  "Write the shortest function that takes one string, and returns a regular expression that matches anything EXCEPT the input string, in parenthesis."

• Compile Regexes:

  "In this task you have to write a program that reads a regular expression and generates another program that outputs whether an input string is accepted by that regular expression."

• Convert Regexes:

  "Suppose you have existing regexes you wish to compile using one of the submissions to Compile Regexes. In as few characters as possible, write a program to make that work:"

All these are code golf challenges where the input or output of the golfed code, rather than the code itself, is a regular expression. So, IMO, we could meaningfully declare that regex-golf should be used for code golf challenges where the code being scored is a regexp, while regular-expression would be reserved for challenges involving manipulation of regexps.

On the other hand, we could also equally well decide that this distinction is not a useful one to make, and that regex-golf should be replaced with regular-expression+code-golf. In fact, I'm personally somewhat inclined in this direction myself, even if it does make the regular-expression tag slightly more ambiguous.

(In any case, the same ambiguity arises also with the other language tags, which can mean either "this challenge is restricted to language X" or "this challenge is about parsing / interpreting / generating language X, but you can use any language to do that". Most of those languages don't have separate tags for these two purposes, and I don't think adding such tags would really be desirable, either.)