The restrictions clause of instructions talks about standard library but in Zig the function it is trying to restrict is a builtin instead. So most students just return @popcount() and call it a day. This defeats the purpose of the exercise.
It would be helpful to explicitly tell the student that @popcount() builtin is not allowed. Or you could restrict all builtins altogether in addition to the standard library.
Those instructions come directly from the problem specs and are used across all tracks. Do you have a specific suggestion for a better way to phrase it that would work for every track?
Keep your hands off that bit-count functionality provided by your language or its standard library! Solve this one yourself using other basic tools instead.
On the other hand, enforcing restrictions with tests is even better. Do you know a way to restrict @popcount() in Zig?
This could be a good candidate for a discussion about a change to the problem specifications. The problem specs are independent of the Zig track.
If the language provides a standard library, aren’t those two things the same thing?
I’m not a Zig maintainer and I don’t know Zig so I can’t help you there. That’s a good question/suggestion for the Zig maintainers, though!
I don’t recall which tracks (languages) do that (there’s over 70 tracks), but I do recall seeing some tracks unload/mock out/block the use of the builtin functions for some tests. More often than not, though, we tend to take the approach that, if students want to take shortcuts and not fully solve an exercise themselves, that’s their prerogative and we’re not going to worry about it too much.
Typically. Scheme comes to mind though where you have a core language which is very minimal and missing a lot but there are different standard libraries thanks to R5RS, R6RS, and R7RS being used in different implementations of the Scheme specifications.
I’m somewhat against including this bit about not using the standard library in the instructions though. Either we do it for all exercises or not at all. Eliud’s Eggs isn’t special. Also, this seems something easily done as an append for tracks that do want students to implement their own solution. For other tracks, it might be expected to use the standard library if available so they would need an append here to say so.
I think the goal (at the problem spec level) of this class of exercise (bit counting, square root, complex numbers, list ops) is for students to implement their own solution. This should hold true for all tracks as that’s the intention of the specs.
Point taken. List Ops and Square Root allude to not using the standard library, but Complex Numbers and this exercise specifically say to avoid the standard library.
They are most definitely not the same in Zig. Standard library is what you import like this
const std = @import("std");
while builtins are functions with names that start with @ and you do not need to import them. See how you use builtin function @import() to even gain access to the standard library?
I had assembly languages (Nibbly November) in mind when suggesting the exercise.
Keep your hands off that bit-count functionality provided by your standard library!
This guidance is intended to cover builtins and machine instructions, without confusing students unfamiliar with such terms.
For the Zig track we could perhaps add a instructions.append.md, like Python has for square-root.
Perhaps
Avoid using builtin functions for this exercise.