This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-06
Channels
- # 100-days-of-code (15)
- # beginners (32)
- # calva (2)
- # cider (37)
- # clara (1)
- # cljs-dev (47)
- # clojure (177)
- # clojure-boston (1)
- # clojure-dev (2)
- # clojure-germany (1)
- # clojure-greece (5)
- # clojure-italy (13)
- # clojure-nl (2)
- # clojure-sanfrancisco (1)
- # clojure-uk (72)
- # clojurescript (46)
- # cursive (20)
- # datascript (7)
- # datomic (14)
- # devcards (6)
- # docker (1)
- # duct (1)
- # emacs (1)
- # figwheel (3)
- # figwheel-main (151)
- # graphql (2)
- # hyperfiddle (1)
- # interop (3)
- # jobs (3)
- # lumo (2)
- # off-topic (21)
- # pedestal (1)
- # re-frame (9)
- # reagent (25)
- # shadow-cljs (57)
- # slack-help (4)
- # specter (21)
- # tools-deps (53)
- # vim (2)
Did anyone try to implement clojure’s closures with MethodHandle and invokeDynamic? in order to eliminate a huge number of classes
My plan is: - implement IFn on top of MethodHandle (do that in java to handle invokeDynamic) - for each lambda: emit static method with “closes” and lambda args as params. emit MethodHandleFn constructor invocation with MethodHandle to that static method, fixing first n args for closure. Theoretically it should reduce number of classes dramatically - make some vars initialization lazy to reduce startup time further. Or maybe even eliminate vars at all in some cases (with special compiler option) The first problem I see is that every expression type in current Compiler.java takes ObjExpr as an argument to emit method.