Hi again, thanks for the great work with Squint. I have run into an issue regarding the fact that JavaScript has both null and undefined to represent the absence of a value. It is a subtle issue and I can easily work around it, but I nevertheless would like to bring it up in case there is something I can improve inside Squint to make it generate better code.
The following snippet of code represents the issue. The unit test is written so that it all the expectations pass with the current implementation of Squint:
(defn my-fn []
(if false
119
nil))
(test "my-fn-test"
(fn []
(-> (expect (if false
119
nil))
(.toBe nil))
(-> (expect (my-fn))
.-not
(.toBe nil))
(-> (expect (my-fn))
(.toBe undefined))))
What this code highlights is that if I have a function, my-fn, that contains an if-form with one branch explicitly returning nil, the return value of that function becomes undefined instead. But if I test the expression directly without wrapping it in a function, it evaluates to nil.
Is the best advice here to write my code so that it is invariant to whether an expression evaluates to undefined or nil , or is there anything I can do to improve the code generated by Squint here? I see saw the implementation (defmethod emit-special 'if ... in compiler_common.cljc .I don't think CLJS in general cares much about the difference between js/undefined and nil . e.g. the nil? function returns true for both of them
we could add an explicit return null of course.
I'd recommend checking what CLJS does: http://app.klipse.tech/ If there is a difference between an empty fn body, if, etc. and squint we could try to align it
feel free to post an issue about this with examples
Thanks! I will give this some more thought, and if I come up with something I can post an issue.
I see there is a bug here: https://squint-cljs.github.io/squint/?src=KGlmIHRydWUgbmlsIDEp
The nil case doesn't have a return
that one is easy to fix probably and might also fix the other issues
the empty function already returns null
let me quickly solve the if case
Nice!
hmm I can't reproduce it, I'd have to look at this some other time. meanwhile an issue is welcome if you think it matters
OK, thanks for looking into it. It is easy enough to work around but I will submit an issue anyway.
so the issue is specifically about using nil in an else branch right?
that part I can reproduce and is easy to fix. wait up
fixed and published
Thanks, just saw it!