This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (11)
- # babashka (71)
- # beginners (34)
- # calva (25)
- # chlorine-clover (38)
- # cider (13)
- # clj-kondo (1)
- # cljsrn (2)
- # clojure (40)
- # clojure-australia (4)
- # clojure-europe (16)
- # clojure-france (3)
- # clojure-nl (4)
- # clojure-uk (16)
- # clojurescript (27)
- # conjure (2)
- # core-async (41)
- # core-logic (3)
- # crux (30)
- # cursive (1)
- # data-science (1)
- # datomic (16)
- # depstar (19)
- # emacs (7)
- # fulcro (33)
- # graalvm (4)
- # honeysql (20)
- # hugsql (4)
- # jobs (1)
- # juxt (4)
- # off-topic (48)
- # pathom (41)
- # reagent (9)
- # reitit (19)
- # remote-jobs (1)
- # shadow-cljs (20)
- # startup-in-a-month (2)
- # tools-deps (29)
- # vim (3)
I’ve recently released two libraries: https://github.com/athos/power-dot and https://github.com/athos/type-infer.
power-dot: A Clojure library that provides enhanced Java interop that allows you to treat Clojure functions as if they were Java lambdas
type-infer: A development utility to inspect static types inferred by the Clojure complier
Give it a try!
enjoyed checking out both, particularly
power-dot, merely as a musing: I don't find the
reify examples so bad - they're concise enough and transparently reflection-free.
The main problem is probably discovery, e.g. it's hard/tedious to know in advance that
.. (IntStream/range ...) can be auto-completed to
filter, and that similarly, filter can be auto-completed to
It seems plausible to me to conceive this as a problem that could be solved in https://github.com/alexander-yakushev/compliment (the lib that powers the auto-completion of CIDER et al).
Basically teaching it to understand functional interfaces + to emit completions that are more substantial than a single symbol (e.g. emit a whole
(reify ...) as a completion)
Thank you for trying them out! I’m glad to hear that 😄
TBH I think method auto-completion is “too dynamic” a problem to solve with power-dot. As I mentioned a bit in the README, type-infer does type inference with the help of the Clojure compiler and due to that limitation, the target expression of type inference must be evaluated eventually. In this respect,
infer is almost the same as
If it’s acceptable to evaluate subexpressions, I think it’s much easier to simply call
(infer (println "hello")) ;; prints "hello" ;=> nil
evaland check the runtime type of the value.
Hi all. I’ve built a new clojure-based library and microservice for SNOMED CT : https://github.com/wardle/hermes. This is a terminology useful in health and care applications. It’s the first of a series of composable libraries to provide some foundational healthcare system services, and my first real clojure product. Clojure’s been amazing in supporting this - I struggled to implement the expression constraint language or more complex logic in the prior versions of my SNOMED tooling - built either in Go or Java. Thank you to those who’ve built the software and libraries I’ve built upon!
Looks interesting! Maybe this is evident to insiders of the field, but I'm curious what is meant by "inference" here.
Thanks. Basically because SNOMED is an ontology we can use the relationships (triples basically) to infer that, for example, you have a type of neurological disease if I know you have Parkinson’s disease. But it isn’t limited to diagnostics but lots of different domains including occupations, countries, procedures, drugs etc. See https://www.snomed.org/snomed-ct/five-step-briefing I use in an EPR.
Looks pretty nice! Some day we might have to integrate with SNOMED as well and then this will be an invaluable resource to either use directly as a service or at least as inspiration 🙂 Thanks for sharing!
Thanks both. @U04V15CAJ - DRE looks interesting! Would be lovely to compose clinician-facing tooling for clinical patient management WITH tooling for making sense of clinical literature. Both are trying to make sense of too much information and both complement each other.
@U013CFKNP2R thanks. For people like me, "deductive inference" or "logical inference" would remove most of the ambiguity, as it would no longer be confusable with "statistical inference".