Closed equwal closed 5 years ago
I'm not sure about this, because they're different values under the hood: __
is :fill-in-the-blank
and ___
is a function that returns that value.
I see why it looks appealing - right now, the effect is the same when running lein koan run
. But I think that's because the error reporting kind of swallows the stack trace when the __
function (the keyword) is passed any number of arguments except 1 or 2. I don't necessarily want to tie too tightly to the current error reporting, and I want things to basically make sense when people work in the REPL.
Here's an example of what I mean. For each of the below cases, I'm comparing the existing behavior of ___
to the behavior of __
.
koan-engine.runner=> (((fn [] ___)) 4 5)
:fill-in-the-blank
koan-engine.runner=> (((fn [] __)) 4 5)
5
koan-engine.runner=> ((fn [f] (f 4 5)) ___)
:fill-in-the-blank
koan-engine.runner=> ((fn [f] (f 4 5)) __)
5
koan-engine.runner=> (___ (fn [n] (* n n)))
:fill-in-the-blank
koan-engine.runner=> (__ (fn [n] (* n n)))
nil
koan-engine.runner=> (defn square [n] (* n n))
#'koan-engine.runner/square
koan-engine.runner=> (___ square)
:fill-in-the-blank
koan-engine.runner=> (__ square)
nil
I much prefer the :fill-in-the-blank
behavior for these, and think that explaining the behavior of __
in these cases is going to be more confusing as folks work through it on their own to find that keywords can act as functions of 1 or 2 arguments, returning nil
when the lookup finds nothing. So I'm going to close this one, but thanks for the effort!
Also, minor side note for next time - lein koan test
helps us make sure things keep working. This PR fails lein koan test
, but it's for mundane reasons instead of finding the stuff I described above - the structure of resources/koans.clj
fills in all the __
and ___
in order, so this one failed because the ___
answers didn't get used.
Thanks for taking the time to go through this. I wasn't using lein koan
to run the koans, I was just compiling each file as I went along in my IDE.
May as well be consistent and use the same double underscore everywhere. This consistency could make it easier to write code in the future which relies on it, and is just nicer I think.