I also like to create many small functions because it makes sense to me. For one off functions however, I define then locally with a let (and letfn) instead of polluting the namespace. I tend to avoid private functions (`defn-` or defn ^:private).

Hah! Didn’t know about letfn. Thanks! 😄

you also can do simple (let [fn-name (fn fn-name* [] body...)] *(optional for recursive calls)

Many small functions can make things easier to test and understand, if divided up well.

Take a glance through the clojure.core source code some time, just to see how small a lot of things are. Certainly some are large, but not many, and some of them are only large because it helped to find a way to make them perform better by doing so.

I like to do some ascii-magic to separate things

;; ================
;; Section 1
;; ================
(defn a []
 "")
;; -------------
(defn b []
  )

(imagine that the dashes or equal signs went to character 80)

and i roughly try to make it so my namespaces read well

just having the visual separation and grouping helps with the number of functions

It depends on what you end up doing with that data. But calling clojure.edn/read-string on an untrusted input should be safe.

For example, if I were a malicious person trying to get around these restrictions, note that many Clojure functions like map , mapv , filter , etc. take a function as its first argument. If I can write code that takes a function as an argument, then passes it on to one of those, then they can be executed.

eval should definitely not be on your whitelist, but it isn't the only thing that shouldn't be there.

Clojail is one project that tries to do some things like this, but I doubt there is any kind of proof of security anyone has done on it: https://github.com/Raynes/clojail

Clojail also doesn't work with Clojure > 1.6. Or maybe even older.

oh yeah I'll have to think about how to use the higher order functions safely

Good to know. Someone may have created updated versions and published them, or similar library that is more recent. I haven't looked. It still may be worth examining if there is nothing else more recent, to learn from.

I was looking at this a little bit: https://github.com/fif-lang/fifql which uses a stack based language built on clojure, for remote (whitelisted) code execution, wondering what are the barriers to doing a more lispy/clojurelike version

FYI, Clojure wasn't designed with 'jail' type execution safety in mind. It was designed to give you power, and let you decide what you want to do with it. This can very likely make a provably safe thing like Clojail either impossible, or at least challenging to get right. If you want "higher hurdles for malicious people" or "door locks, to keep the honest people out", it is likely a good enough approach. Anything else, and I think you are looking at full-time security researcher with expertise in breaking system security type work.

It may be worth noting that maybe you don't need to support functions at all if you implement a rich enough DSL on top of that EDN.

Thanks for the tips again 🙂 useful to know this is probably not he right path

FYI, I think a path like this is exactly what some web sites that let you enter Clojure code, e.g. http://www.4clojure.com. uses. However, they probably also run it in a VM, and give it no access to anyone's private data, so even if the jailing fails, the worst that is likely to happen is it hogs the VM for a while until someone kills that.

I was delayed in checking out Sci, but it seems to be exactly what i want actually, thanks!