2023-09-01 cljs-dev | Clojure Slack Archive

cljs-dev 2023-09-01

dnolen 2023-09-01T17:45:43.254109Z

@alexmiller @fogus I’m curious if there any known edge cases w/ top-level closures? there seems to some interest in supporting this better

gnl 2023-09-02T15:45:52.709659Z

@dnolen – to be more specific, is it fair to assume that it's only letfns support for forward declarations/mutual recursion that causes these compilation issues, while top-level closures with a plain let don't?

gnl 2023-09-02T16:01:51.662689Z

I've since moved to using top-level (let [f (fn ...)]) instead because I rarely need letfns forward declaration support and in the cases where I do, I can still define regular private top-level functions and declare to achieve this (might go against my personal code style preferences in this case, but it's rare enough that it's fine). So if it turns out that properly supporting top-level letfn in ClojureScript is a huge amount of effort or cannot be done without breaking advanced compilation at this time, I'd personally settle for a (hopefully temporary) compiler warning and a note in the ClojureScript documentation. The biggest problem here is really that the expectations-defying scope-breaking behaviour is silent.

dnolen 2023-09-04T13:22:10.283629Z

no top level closures period caused problems

👍 1

dnolen 2023-09-04T13:22:42.891489Z

but admittedly it was a long time ago and it needs testing

dnolen 2023-09-04T13:22:56.950519Z

related was that it defeated cross module code motion for code splitting

bronsa 2023-09-01T17:56:12.139989Z

if you're asking about clojure, i'm not aware of any reason why top level closures would cause issues, this seems like a specific bug in the cljs emission

bronsa 2023-09-01T17:57:44.042789Z

and it's a perfectly valid pattern to use. admittedly using letfn to do a "let over lambda" is not as common as using let, but they both should be supported IMO (and they do work as one'd expect in clojure)