Keep your hands off that bit-count functionality provided by your standard library! Solve this one yourself using other basic tools instead.
A couple of days after reviewing and approving the PR that added the exercise to the Clojure track, I decided to add an appendix file stating that any bit-* functions should not be used. Unfortunately, by excluding all bit-* functions, I was also excluding functions like bit-shift-right, which is allowed. Then, the maintainer who created the PR clarified that the restriction was intended to prevent solutions using a single function to solve the exercise. Realizing my mistake, I removed the appendix file and merged.
A day later, I understood the problem: since Clojure lacks a bit-count functionality, I had misinterpreted the instructions. If I misunderstood, I expect others might as well. In fact, many may interpret the restriction as:
don't use bit-* functions, and don't use the count function
To prevent similar confusion not only in Clojure but also across other tracks, Iâd like to suggest a different way to phrase the restriction:
Avoid using any library functions that directly count the number of bits in a number. Instead, try solving this yourself using more basic tools.
Thoughts from other maintainers?
Edit: The word âdirectlyâ isnât strictly necessary. A more general restriction would be:
Avoid using any library functions that count the number of bits in a number. Instead, try solving this yourself using more basic tools.
It might be that adding âif it existsâ would be enough, in that first sentence.
It is coming from Problem Specifications and as that addresses all the tracks, it might be good for the change to happen there. An addendum is possible for expanding the information in the individual track.
Thatâs another possibility, but my main concern is that if something doesnât exist, it can easily be misinterpreted. Clojure has both bit-* functions and a count function. Iâd rather have a description that clearly states the intention of the restriction, rather than leaving people to guess.
The appends file is meant to clarify track specific communication, and I think that if the communication is unclear in problem specifications, we can âgenerallyâ improve it by suggesting that we are stating something that may not be true for the language, and then have the track maintainer clarify that in the append for each track in which this is true.
That is what it is there for, anyway. So, for Clojure, I suppose, we should discuss that in the Clojure - Exercism category, and for each language track.
I would say that some tracks have a count functionality that has nothing to do with bit operations that may be used, and so stating to not use them may not, also, be the right direction to try to distract. There is just too much variances that we can not cover them all in the main description on Problem Specifications and any clarifications that need to be done should be done in the additional document that gets processed for the individual track as it applies.
This is why I would likely go with something that does admit âambiguityâ such as âif it is existsâ as the main document is best to describe the exercise description and perhaps general suggested approaches, but not specific approaches, as it can not possibly cover those.
@kotp I agree; however, the proposed change is just a rewording of the existing restriction. I donât intend to modify anything else.
As for append files, Iâm not really a fan. They seem like a continuation of the description, but theyâre not synced automatically with the main text. This creates the risk of them going out of sync with the main description or containing redundant or duplicated information.
For this specific exercise, Iâd rather not add an append file, as this could steer students toward specific implementations.
For long standing example, Strain, since 2016, it has similar wording. See exercises/strain/description.md from the problems-specifications repository, and 50+ languages that have this similar wording.
Specifically, and as an example of a track using an append file, see Crystal.
You are completely disregarding the fact that this wording confused me, leading me to assume that I shouldnât use functions that are actually allowed. I have no way to resolve this with an append file. If you can provide a specific example of how I could resolve this, Iâd like to hear it.
An append file that states âsince there is no bit-count function in this language, we are asking you to build this.â may work. I did not look at the denied pull request from the Clojure maintainer, but I also do not really accept that this can not be attended to by an append file.
I just saw this commit and yes, it is the wrong thing, as discussed, but I also did not see where the maintainer would disallow an append file that is more precise rather than what this was, which as you agreed was too broad.
Making changes at the Problem Specifications level is going to be far reaching, as it affects 70+ tracks, so having the more generic wording, avoiding âfunctionâ and âmethodâ and âprocedureâ and other language specific things is going to cause confusion in other ways.
But specifically, for this reported problem as stated in the original post here, and specifically for the Closure track, from your descriptions:
An append file that states
The `bit-count` function does not exist, but writing a function that counts the bits in a binary number is what we are aiming for in this exercise.
That may be too directive, but would be better, in my opinion, and as expressed in your original message, than âavoid all bit functions, including functions called count .â
Keep your hands off that bit-count functionality provided by your standard library!
Solve this one yourself using other basic tools instead.
was to be consistent with other exercise(s).
Part of the intent was that assembly language students avoid using popcount instructions for this exercise, i.e. avoid bit-count functionality provided by the instruction set.
In my opinion, the reverse-string exercise should also have some guidance to avoid built-in functionality, I donât have specific wording preferences.
But the restriction doesnât talk about a bit-count function. It talks about bit-count functionality. This append file essentially achieves nothing and is unrelated to my original problem. I never said i had a problem with a bit-count function.
Never mind. Iâll mark this as resolved to bring this discussion to an end. Thatâs as far as Iâm willing to go. Iâll find a way to deal with it.
To me, it seems that the best approach for any specific restriction is to avoid stating it in the instructions altogether. If a language wants to enforce restrictions, they can do so using an append file.