How about something like Your task is to, given a target word and a group of candidate words, to find those candidates that are anagrams of the target.? That moves us away from using sets and supersets which don’t seem to improve the instructions’ clarity.
By keeping sets/supersets in, I’d likely have to forego this exercise in Arturo since it doesn’t have a set type for me to use as input/output. Blocks can be used with the set operations available in the standard library, but they are not sets. The Euphoria track would have the same issue since they use sequences like Arturo uses blocks.
You can add a track specific insert that the results should be sorted lexicographically / alphabetically or sorted the same as the input.
Why are we discussing changing problem-specs when tracks implemented this incorrectly? Why are we not considering that an unordered set (or even array!) makes more sense given the instructions than an ordered result? Why make the problem specs more ambiguous?
It makes it harder to implement and more ambiguous. This basically forces all tracks to add an insert into instructions how it’s implemented in that track.
I don’t understand why you’re not considering this burden.
This seems to be one of the exercises where the canonical data clearly implies order, whereas the description refers to sets.
I checked Python, JavaScript, and Java, and all of them use ordered structures. This suggests that most tracks are likely not using sets.
So, another option could be to check how many tracks have implemented this based solely on the description and consider updating it to use ordered structures, such as lists or arrays.
A sublist is not a defined thing in all languages, and I don’t think it was intended to mean “sub-ordered-data-structure” nor does that say that the result must be ordered the same way the source was.
This is the right approach in my opinion. The least total burden is my preferred solution here. Removing words from the description to make it more ambigous adds the burden to each implementing track.
I strongly feel for updating the JavaScript one to test order independent. I don’t think subset or sublist indicates order, and I think the intention was “make sure the right items are present in whatever data structure you return” and not “keep the order intact”. It limits the solution space.
This wasn’t clear to me at all until you said it. I just presumed we could remove the wording and it wouldn’t cause anyone any work. Now you’ve said it I realise that the tracks that have that guard would need to add a constraint, so it would cause work. But I think probably neither Isaac nor me had realised that
We could not have the language and have a test anyway, but I don’t think that would be good here, as it can be quite a fundamental part of the decision.
I’m confused. I thought we intentionally and explicitly avoid putting the finer implementation details into the specs and rely on the tests to be the specs. Tracks need to implement tests and, however the track tests are implemented, that is the requirements for that track. Some ambiguity in the instructions is a feature, not a bug.
If the majority of the tracks do X and the specs say Y, I’d think the issue is with the spec, not the tracks.
I think the issue is that we treat problem specs as idempotent now, to avoid discussions like this. So once something’s in the spec, it’s in the spec. For it to be changed, we basically need a pretty unanimous decision on it. (Because of all the giant fights that used to happen, which DJ still has embedded trauma from )
Same with this. I agree that we do, but once it’s in the text and lots of tracks have implemented it, I think we’re sort of in trouble.
I’m 1-1ing with DJ because I don’t really understand fully what the pain is. Then I’m going to sleep. Once I understand and I’ve slept I’ll write some thoughts up here tomorrow.
I hate that we’d have text that says “They can be any order” then more text that says “Oh wait, they can’t actually”.
DJ feels its important that tracks specify ordering, because depending on people’s backgrounds they may or may not default to ordered structures (ie someone coming from a language without ordered lists going to one that does). And as it could be quite a fundamental implantation detail, having a final test that tests one way or the other could lead to a bad experience.
The confusion on this thread between people from different backgrounds reenforces (2) IMO.
So, one solution would be to make a list of tracks that have this implemented, and split whether they were ordered or not, and then:
Remove the text from Prob Specs
PR all tracks with one insert or the other (ordered or not ordered)
And everyone is happy.
If anyone feels like doing that, that’d be great. If no-one wants to do it, this probably stalls.
@brasse You started this chaos - how do you feel about scripting 80 PRs and getting loads of Exercism reputation points?
I wouldn’t be opposed to doing this. Though it would be helpful to have an agreed upon append text before creating PRs so there aren’t 80 different discussions about the append wording.
Proposed instructions removes any reference to “sets” and “order”.
Thoughts?
Proposed instructions
Given a target word and some candidate words, your task is to find the candidates that are anagrams of the target.
An anagram is a rearrangement of letters to form a new word: for example "owns" is an anagram of "snow".
A word is not its own anagram: for example, "stop" is not an anagram of "stop".
The target word and candidate words are made up of one or more ASCII alphabetic characters (A-Z and a-z).
Lowercase and uppercase characters are equivalent: for example, "PoTS" is an anagram of "sTOp", but "StoP" is not an anagram of "sTOp".
The words you need to find should be taken from the candidate words, using the same letter case.
Given the target "stone" and the candidate words "stone", "tones", "banana", "tons", "notes", and "Seton", the anagram words
you need to find are "tones", "notes", and "Seton".
Append: unordered
The order of the words you find does not matter.
Append: sorted
The order of the words you find must be in alphabetical order.
Append: set (assumes data is returned and a set object)
Your solution should return the answer as a set object.
59 expect the results to be in the same order as the input. If I read correctly, the function must return a list with elements in the same order as they are given in the candidate list.
7 tracks do not care about the result order.
3 tracks expect a set or hashset object (Cairo Kotlin Rust)
4 do work in the test code to ignore order (Python: count occurrences, awk: check existence, Perl: convert to a set/bag, Erlang: sort)
2 expect alpha-sorted results (Euphoria, VBNet)
I have no idea what UIUA does. I can’t read that language. I think it expects the candidate ordering?
C is “none of the above”; you’re given a collection of candidate objects and you need to update each object’s bool flag.
I don’t want to add to the chaos, but I also do not want an append for Python. Especially not an automated or mass one. So please leave the Python track out of any mass PRs for addendums.
We’ve (incorrectly, I might add - but I will fix itthat method actually checks both the len() and the elements, and also has a sensible default error message! #pythonrocks) implemented tests that intend to check for the included anagrams instead of requiring any particular data structure or order.
Currently, that means checking if the length of returned anagrams matches, but should more properly be checking that any returned data structure contains the correct entries (it actually does both!) - whether or not that data structure is a set, a tuple, or a list. It will also check dictionary keys, but not values.
So that will be my project for the test template for Python. It keeps the instructions as-is, and doesn’t over-complicate things with specificity that’s (IMHO) not really relevant to this problem, which in Python is essentially about iteration and string processing/checking/matching.
Since the function is fed a list by the tests, the vast majority of the solutions will also use a list as a return … but there is absolutely nothing that says a particular data structure be required - and in fact, with the current tests, tuples, sets, lists, and even dictionary keys all work and pass.
FWIW, I have always interpreted these instructions as using “subset” in a non-programming, manner, as a synonym for group. But different strokes for different folx.
Speaking as a track maintainer, I’m also in favor of not having any specific appends to the tracks I co-maintain (awk, bash, jq, sqlite). I think the instructions are sufficient and the rest can be inferred from the tests.
)
Please try to not all fall out in the meantime 
Late to the debate here.
) implemented tests that intend to check for the included anagrams instead of requiring any particular data structure or order.