Fork me on GitHub
#cljs-dev
<
2023-09-01
>
dnolen17:09:43

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

bronsa17:09:12

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

bronsa17:09:44

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)

fogus (Clojure Team)18:09:07

@U050B88UR I'm not aware of edge cases off the top of my head. I'll look to see if there are any that I just don't know about.

dnolen18:09:08

@U060FKQPN is not really bug, it’s not been supported because the compilation model

dnolen18:09:22

generating top level closures used to interact extremely badly with advanced compilation

dnolen18:09:45

so further support the pattern was halted

dnolen18:09:10

@fogus in particular I’m curious about the case of AOT

gnl15:09:52

@U050B88UR – 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?

gnl16:09:51

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.

dnolen13:09:10

no top level closures period caused problems

👍 2
dnolen13:09:42

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

dnolen13:09:56

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

dnolen17:09:09

@alexmiller also I see you ran the release thing 2 weeks ago successfully, was that just a test?

Alex Miller (Clojure team)18:09:18

I ran it with deployment it off I think

Alex Miller (Clojure team)18:09:33

yes, it was a test, and it did not actually make a public release

Alex Miller (Clojure team)18:09:43

but if you ran it now, it would :)

dnolen18:09:18

will try it out now

Alex Miller (Clojure team)19:09:32

it appeared to work, but I don't see the release out there

Alex Miller (Clojure team)19:09:11

well, I do see it in Maven Central UI and I can download it (v 1.11.121) so I guess it's ok

Alex Miller (Clojure team)19:09:50

ah, just lexically sorted in the repo directory so I missed it