Fork me on GitHub

I’ve recently released two libraries: and • 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!

👍 19
😀 1

enjoyed checking out both, particularly type-infer :) wrt 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 IntPredicate. It seems plausible to me to conceive this as a problem that could be solved in (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 eval:

(infer (println "hello"))
;; prints "hello"
;=> nil
If it’s acceptable to evaluate subexpressions, I think it’s much easier to simply call eval and check the runtime type of the value.

👍 1
Mark Wardle21:02:08

Hi all. I’ve built a new clojure-based library and microservice for SNOMED CT : 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!

👏 4

Looks interesting! Maybe this is evident to insiders of the field, but I'm curious what is meant by "inference" here.

Mark Wardle06:02:30

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 I use in an EPR.


@U013CFKNP2R We're using similar technology in our stack at Very interested to see what you did.

👍 2
🙏 1

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!

👍 1
Mark Wardle09:02:47

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".

Mark Wardle11:02:40

Ha! Ontological inference. But I do both statistical work and ontological work and have no difficulty swapping the meaning (pun intended) 😉 "Inference: the process of inferring something."