What the subject says basically. I’m looking at the Anagram exercise in the Common Lisp track. It suggests that the solution should return a set of anagrams, i.e. a list where the order of the elements does not matter. The instructions even says so explicitly. However, the tests do take the order of elements into account.
How do I go about making this situation better?
Hello, thanks for posting.
Firstly, giving us some code would be good. So here some code and the error you get about them being in the wrong order.
Then we generally need to agree what needs to change (instructions, tests, etc) and we’ll suggest a route forward.
Opening the forum discussion is the right way to start 
OK! Here is my solution for the exercise:
(defpackage :anagram
(:use :cl)
(:export :anagrams-for))
(in-package :anagram)
(defun sorted (s) (sort (copy-seq s) #'char-lessp))
(defun anagram-p (subject candidate)
(string-equal (sorted subject) (sorted candidate)))
(defun anagrams-for (subject candidates)
"Returns a sublist of candidates which are anagrams of the subject."
(reduce #'(lambda (acc x) (if (anagram-p subject x)
(adjoin x acc :test #'equal)
acc))
(remove subject candidates :test #'equalp)
:initial-value ()))
This is the output from the tests:
Did 18 checks.
Pass: 14 (77%)
Skip: 0 ( 0%)
Fail: 4 (22%)
Failure Details:
--------------------------------
HANDLES-CASE-OF-GREEK-LETTERS in ANAGRAM-SUITE []:
(ANAGRAM:ANAGRAMS-FOR "ΑΒΓ" '("ΒΓΑ" "ΒΓΔ" "γβα" "αβγ"))
evaluated to
("γβα" "ΒΓΑ")
which is not
EQUAL
to
("ΒΓΑ" "γβα")
--------------------------------
--------------------------------
DETECTS-MULTIPLE-ANAGRAMS-WITH-DIFFERENT-CASE in ANAGRAM-SUITE []:
(ANAGRAM:ANAGRAMS-FOR "nose" '("Eons" "ONES"))
evaluated to
("ONES" "Eons")
which is not
EQUAL
to
("Eons" "ONES")
--------------------------------
--------------------------------
DETECTS-THREE-ANAGRAMS in ANAGRAM-SUITE []:
(ANAGRAM:ANAGRAMS-FOR "allergy"
'("gallery" "ballerina" "regally" "clergy" "largely"
"leading"))
evaluated to
("largely" "regally" "gallery")
which is not
EQUAL
to
("gallery" "regally" "largely")
--------------------------------
--------------------------------
DETECTS-TWO-ANAGRAMS in ANAGRAM-SUITE []:
(ANAGRAM:ANAGRAMS-FOR "solemn" '("lemons" "cherry" "melons"))
evaluated to
("melons" "lemons")
which is not
EQUAL
to
("lemons" "melons")
--------------------------------
The wording in the instructions is this: The anagram set is the subset of the candidate set that are anagrams of the target (in any order).
This is a common issue across multiple tracks. The instructions come from a shared repository and are identical across all tracks. However, each track can adjust certain parts of the instructions if it better aligns with the exercise or track objectives. The types of inputs and outputs are one such area. If the tests consider the order of elements, you should follow what the tests dictate.
For instance, the Clojure track uses vectors in its tests, so it also takes the order of elements into account.
Is there any reason to have that specific text in problem-specs if it’s incorrect?
If it’s incorrect, it should not be in the specs. But i don’t think there’s anything wrong with specs here. It’s simply that the tracks haven’t chosen to follow the instructions to the letter for various reasons. Should a track use sets? Probably.
Yes, basically what @tasx said. Don’t think the spec should be changed.
Probably would be better to either rewrite the tests to use sets, or just accept that the order of the input should be preserved and then the current tests would pass (maybe an addendum to the instructions)
To me it seems like the cleanest solution would be to rewrite the tests.
Does not changing the spec and adding an addendum to the instruction mean that the instructions will say the order doesn’t matter and then say that the order do matter. Feels very weird to me.
If you want the tests rewritten I can volunteer to do that.
Volunteering accepted. Thank you!
Note: when you open a PR, it’ll be auto-closed and you’ll be told to post on here. If you just link to the PR in this existing thread - we’ll reopen it for you
@tasx @Cool-Katt Thanks team!
OK! Here is the PR: Fix test for Common Lisp - Anagram by brasse · Pull Request #847 · exercism/common-lisp · GitHub
Is there any reason to keep that “in any order” in the specs if that’s not true across multiple tracks? Is there any drawback to removing that bit from the specs? If we update the specs, tracks can still use sets to not care about order … and tracks that do care about the order would be less broken.
The reason is that in other cases the order is significant, so specifying if order is significant is important. This should not have used lists in lisp.
I believe the main reason that tracks have implemented their tests using sequential structures is because the specs use the typical [ ] notation, which is commonly used for lists, arrays, vectors etc.
Based on the canonical data, it appears they also take the order into account. Perhaps we should update the description to remove references to sets? This is a much simpler change than forcing the track to use sets and invalidating existing solutions.
Changing the test to not take order into consideration won’t invalidate existing solutions. And the type used to represent sets is the same. Changing the test just relaxes the passing criteria a little while still having all old solutions passing.
Remove “in any order” from the specs wouldn’t require any track changes and would make either track-specific implementation (ordered or not) “valid”.
It depends on how the tests are written. I don’t know Common Lisp, but after some research, it seems the language doesn’t even have a native set type. Do the tests use a function that performs set operations on lists? That’s very different from stating that the anagrams and candidates are sets, as the description claims.
Since the description is shared across all tracks, updating it won’t require changes to the tests for any track. Much simpler.
That makes sense as well. Just as long as the instructions conforms with the test I’m happy.
Racket also uses lists unfortunately. I’ll PR something later so the student’s result is converted to a set and then compared to a set of expected values. That should avoid breaking existing solutions.
Personally, i’m not doing anything in the Clojure track besides adding an append file if the description isn’t changed. Here’s why. The following is the first line in the instructions:
Your task is to, given a target word and a set of candidate words, to find the subset of the candidates that are anagrams of the target.
It talks about sets as input and output. Changing the input to be a set (in the tests) will invalidate solutions, and converting the result to a set (in tests) isn’t the same as requiring to return a set.