This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-10
Channels
- # announcements (6)
- # babashka (38)
- # beginners (85)
- # biff (3)
- # calva (2)
- # cider (11)
- # clerk (14)
- # clj-kondo (6)
- # clj-on-windows (27)
- # clj-together (2)
- # cljsrn (18)
- # clojure (106)
- # clojure-austin (1)
- # clojure-belgium (1)
- # clojure-europe (19)
- # clojure-nl (1)
- # clojure-norway (9)
- # clojure-uk (2)
- # clr (2)
- # cryogen (1)
- # cursive (10)
- # datahike (3)
- # datavis (2)
- # datomic (15)
- # emacs (7)
- # graalvm (10)
- # graphql (20)
- # gratitude (1)
- # hyperfiddle (1)
- # improve-getting-started (23)
- # joyride (24)
- # london-clojurians (1)
- # lsp (22)
- # malli (4)
- # matcher-combinators (3)
- # membrane (13)
- # off-topic (1)
- # pathom (24)
- # polylith (9)
- # react (31)
- # reagent (9)
- # releases (1)
- # remote-jobs (1)
- # reveal (3)
- # shadow-cljs (50)
- # spacemacs (3)
- # specter (5)
- # xtdb (5)
@dmiller Got to looking at https://github.com/camsaul/methodical (a rethink and re-implementation of multimethods) and as I perused the source code I could not detect a single namespace that could not in good conscience be a cljc file (with at most one or two places where a reader conditional might be needed). IOW, this looks quite ripe for porting to ClojureCLR. The only question is whether it assumes AOT (it imports types and protocols defined elsewhere in the project, most of which, again, could be cljc files instead of clj files) in which case the port might be limited to .NET Framework (fine for my initial use case). But I just wanted to get your take on it.