1
\$\begingroup\$

This question was put on hold as unclear.

I thought it specifies exactly the requirements, the objective, and the winning criterion.

Could somebody kindly explain what's unclear about it?

update: I've edited to remove an out-of-place sentence. Is the question good now?

update 2: I've deleted the question. Thanks for the helpful feedback.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ It looks to me like you thought of a clever solution and tried to make a puzzle by allowing only the things you used in your solution. I find this a poor way to make a golf challenge, as it's all about finding the trick you have in mind. That is, besides the fact that the allowed operations are unclear. \$\endgroup\$
    – xnor
    Sep 18, 2016 at 19:20
  • \$\begingroup\$ @xnor yes, but it is not about clever trick, but what's behind it. and it's not so clever, I actually was concerned it'd get dismissed as too simple. The allowed operations are: equality operator; your language's list comprehension facilities; your languages list enumeration facilities (like in Python's range). I don't understand what is unclear. -- I found this way of writing it down, found it nice and entertaining, and wanted to share this and give others opportunity to discover this for themselves. Isn't it why Qs get asked here on PCG? Or so I thought. \$\endgroup\$
    – Will Ness
    Sep 18, 2016 at 21:14
  • \$\begingroup\$ I agree the challenge is ambiguous, but I appreciate that this was not intentional and you have put effort into making it as clear as possible. It has taken a long time for this community to learn what works and what doesn't, and the reasons can take time to grasp. In the meantime, I want to emphasise that explaining the problems isn't meant to discourage you from posting. Writing challenges is a difficult challenge in itself. Even people who have been posting challenges for years still use the sandbox. \$\endgroup\$
    – trichoplax is on Codidact now
    Sep 18, 2016 at 22:55
  • \$\begingroup\$ @trichoplax explaining the problems can only be good; it is discussion; silent downvoting and closing is what leaves one baffled. I still don't understand what's so confusing about the Q; any ambiguity as to what list comprehension is, is intentionally left to be defined by your language. That was another point for my asking, to see what's out there. Thanks for the link! \$\endgroup\$
    – Will Ness
    Sep 19, 2016 at 7:39
  • 1
    \$\begingroup\$ @trichoplax I had no idea the sandbox existed. Your responses feel really helpful to me, thanks again. \$\endgroup\$
    – Will Ness
    Sep 19, 2016 at 7:57
  • 1
    \$\begingroup\$ The trouble with "defined by your language" is that different languages use different terminology, or worse, the same word for something different, so that saying which features fall into a given category can become very subjective. This meta answer sums up the general problem pretty well. The other answers there are worth browsing too, as there are lots of things which you might not expect to cause problems until after writing many challenges. \$\endgroup\$
    – trichoplax is on Codidact now
    Sep 19, 2016 at 9:13

1 Answer 1

Reset to default
4
\$\begingroup\$

Whitelisting permitted syntactic constructs is almost always a disaster. It can just about work if answers are restricted to a single language and the full grammar of that language is given in the question, but in general you'll find that restrictions designed with one language in mind are completely unintelligible when you try to interpret them for an unrelated language.

In the particular case of the question you cite, it seems to me that the current wording prohibits the use of variables, but I can't tell whether you intended that or not. I've no idea how you intend list comprehension and list enumeration to be interpreted in languages other than Python (and I'm a bit vague on what exactly they mean in Python, although people who actually know the language probably understand).

PS See also

\$\endgroup\$
6
  • 2
    \$\begingroup\$ I golf mostly in Python and don't totally understand what those terms allow. Ranges? The function enumerate? For loops? Lists comps with an if condition? Set comprehensions? \$\endgroup\$
    – xnor
    Sep 18, 2016 at 19:12
  • \$\begingroup\$ Thanks. They are not syntactic constructs, but concepts. I don't know Python much beyond the basics, but Wikipedia has an article on list comprehensions with a lot of languages listed in it, so I thought it is a clear concept in each of those languages. As for list enumeration, I tried to clarify by referring to "Python's range". Then I forbade the use of any operator except the equality operator. What's unclear about that? As for variables, I made no mention of them, so why should they be restricted? Anyway, the Q was downvoted and closed without nary a peep from anybody. I would clarify. \$\endgroup\$
    – Will Ness
    Sep 18, 2016 at 21:03
  • \$\begingroup\$ @xnor whatever's in the Wikipedia article on list comprehensions, no? I wanted to see what is there in other languages. I figured if there's a WP article, the concept is widely known and clear. In any case, nobody asked anything. \$\endgroup\$
    – Will Ness
    Sep 18, 2016 at 21:07
  • \$\begingroup\$ If I wasn't clear, direct answer to your question is, "whatever's intended by your language as 'list comprehension', if it has it". I've edited the question with clearer wording (hopefully) and added link to Wikipedia. @Peter \$\endgroup\$
    – Will Ness
    Sep 18, 2016 at 21:46
  • 1
    \$\begingroup\$ @WillNess, I didn't actually pose a question: my intent was more to point out that this kind of restriction generates an almost infinite number of "Does X in language Y meet the restriction?" questions. But if you do want to answer the example implicit questions, the one about variables is IMO a bigger stumbling block than the one about list comprehensions. Note that it's not as simple as saying "You can use variables": you've explicitly banned all but a whitelist of operators, and some languages can't use variables without using assignment and access operators. \$\endgroup\$
    – Peter Taylor
    Sep 19, 2016 at 8:02
  • \$\begingroup\$ @PeterTaylor thanks for the clarification. I meant arithmetic operators mostly (but equality can be non-arithmetic too, and in fact I use it in both senses). Maybe it'd be better to just explicitly ban +,-,*,/,%, and allow anything else... Will think it over. \$\endgroup\$
    – Will Ness
    Sep 19, 2016 at 8:05

You must log in to answer this question.

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