Is there a specific reason why you are putting the symbol in the map, instead of the function itself? Otherwise, putting the function instead of the symbol would remove the need for invoking resolve. Also, you can take a look on dynamic vars and binding, which would remove the necessity for the map. Since I am also a beginner, I am interested in seeing some other technique for doing this.

well I have defined like default input and output functions somewhere... which are stupid read-line and println respectively

but I want my application eventually to work with web input and render to html as output

so I want all the other program be totally unaware where it is geting it's input from and how output is being performed... so I was thinking to put those references of functions into map which is in general whole data of whole program, and when passing around, it is used by program to read and write stuff

I see. I will come up with a quick binding example, I believe it will suit your needs

with my guts I feel I am not doing it idomatically, but how else one can reference functions?

(def ^:dynamic *my-input* 3)
(defn print-my-input
  []
  (println *my-input*))
(print-my-input)
(binding [*my-input* 200]
  (print-my-input))

well I don't think this is the case

Instead of the number, you can use a function

what I want is to have data structure, which also contains (by keys) function which can do something, like input and output itself

and then program which uses the data structure, just looks up the input/output function by key inside the data strucutre, and uses it to get inptuts and outputs

I need dynamically reassignable function, not value

ahh

You can define the dynamic var as a function. The number was just an example

but then it looks like the var lives separated from my data structure

probably it's my OOP kicking in, but I want to have function of the data strucuture to live inside that data structure - probably bad idea

but it simplifies my program, so that all of my top level functions all take only one parameter - my data structure

and then separate functions just pick parts of the data strucutre, But occasionally input is needed and output is needed, so it would be nice to reference the same data structure for the "currently configured" input/output functions

of course, when the data structure is initialized at the beginning of the program, those input/output functions are defined assigned...

my approach works, but is it good and correct one?

If you want to keep the function in the map, you can put the function itself as the value of the association. Your example was: {:input 'my-input-function} and ((resolve (:input myfunctionmap)) You can remove the quote and the resolve: {:input my-input-function} and ((:input map))

If you want to change the function in the map, just use (assoc map :input new-func)

just found it

so I just made expedriment and it works, looks like this is what I want (def myoutput println) (def struct {:output myoutput}) (let [output-function (:output struct)] (output-function "Whatever"))

yea you are right that ' symbol and resolve are excess

by removing both of them I got nice and clean code - thanks

now I found another problem (in future) With normal console, I know when I need input, and I explicitly ask, and block program waiting for tha tinput But for web... it's not that possible... for that I have to somehow wait for input differently, as user will be invoking some REST API as "input" to my program, and where in the first case app is initiator of input, in other case it is remote user kicking my server through API giving that input at some arbitrary time

That is because the API is more "reactive" than "imperative". Your program will react to requests. You can build the console version of the program in the same way as the web version is. The thing both have in common is the way the input is dealt with, so you can separate this logic in a pure function. The difference is the way the input is taken, so you will have to separate the read/write logic. For the API case, you will get the request, pass it to the logic function, grab the return and write it back to the client. For the console case, you will prompt the user for input, pass the input to the function, grab the result and output to console.

Things will be easier if you separate the logic from the input/output handling

Instead of putting the in/out funcs in the map, you can completely remove them and pass only the data to the function. The function will return the result and then you deal with giving it back to the client. Each interface (API/console) will implement it's own ways of handling IO

yea, I guess I will do this, coz now I see that input/output got inside function which should not do anything of input/output just react on it... and don't care where it came from

that "input/pure/output" sandwitch is what I want to achieve

yes, exactly

ok, thanks... will think about it

this is why people will often talk about building functional systems as an onion. The core will have only pure functions, and the side-effecting functions will be pushed toward the outside

it is way easier to unit test systems like this

yes sure... and that is essential for me too, as I have not much knowledge at all about clojurescript and ring and compojure etc. so until I will get to web, i want to test my program without the web at all... pure console input/output and then I will start learning next things - clojure for web

but as my program in general is "game" (board game) I have to read turns from users, where each user can have several actions on each of their turn So it is somewhat thinking need to be done Like infinite loop of inputs/actions/outputs -> inputs/actions/outputs -> and so until end is reached

That is normal, I am also still learning. It was very hard, especially in the beginning, to wrap my head around the functional style, coming from an objected oriented perspective. It is just a matter of practicing a lot, reading other people's code (libraries, applications, etc.)

and whole game state is kept in one huge map, but then I have to "chop" each step into some "snapshot" of the game, so I can use reactive approach, and always know on what stage where I am

I see. You may want to take a look on Clojure's reference types, to maintain the state of the game as time progresses. That would be useful for both web and console version

Especially in the web version... that would allow you to maintain the the state of the game in memory, and update it as requests come from the web

(in a thread safe manner)

You can define the valid transformations to the game state as functions (as you may already be doing). When a request comes, you decide which operation is to be done, apply it to the current state of the game and get the resulting state as a return from the function. From there, you can write to the reference type and return something to the client

yes, this second part I figured, now I need to remake some stuff, to make the input part correct, and yes, transformations are the one good approach

cool... make sure to come back to the channel and ask if you have any modeling questions. There are pretty smart people in here that can help you

https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/TreeMap.java#L1984

but I see your point. it’s not public

it’s sad that clojure sorted-map aka PersistentTreeMap has no successor func. Feels like I have to do some mambo-jambo to make it work, or write in Java 😢

actually ceilingKey would work just find in my case, since this is what I want, but I want this to be done on PersistentTreeMap - sorry for kinda wrong question though

(apply f [{:x 1 :y 3}]) ?

Good idea, I tried it but unfortunately it doesn’t work.

(defn f [{:keys [x y]}] (+ x y))
=> #'user/f
(apply f [{:x 1 :y 3}])
=> 4

seems to work for me

Right but that’s not a keyword argument function

(f :x 1 :y 2)

(apply f (flatten (vec {:x 1 :y 2})))

you should use concat instead of flatten

@UCQL6E7PY I’m having trouble piecing together how concat would replace flatten in this case?

(apply f (mapcat identity {:x 1 :y 2}))

my bad! apply concat

(apply f {:a 1 :b 2})
;; => ([:a 1] [:b 2])
;; we want the return to be (:a 1 :b 2) for the {:keys [...]} syntax to work.
(apply f (flatten (vec {:a 1 :b 2})))
;; => (:a 1 :b 2)
;; works when the input is not a collection
;; but fails in this case:
(apply f (flatten (vec {:a [1 2] :b [[[3]]]})))
;; => (:a 1 2 :b 3)
;; using concat ensures only the top level is joined: 
(apply f (apply concat (vec {:a [1 2] :b [[[3]]]})))
;; => (:a [1 2] :b [[[3]]]) 

with apply concat I don't think vec is needed anymore either

(apply f (apply concat {:x 1 :y 2)))

(apply f (mapcat vec {:x 1 :y 2})))

Thanks for explaining!

no problem! mapcat vec works, but I'd expect it'd be a little less performant due to the calls to vec. Ultimately probably not a big deal

Or

user=> (apply f (into [] cat {:x 1 :y 3}))
4

@U8WFYMFRU Is core.typed on your radar? If so, you'll find it (currently) impossible to type-check such calls. See https://circleci.com/blog/why-were-no-longer-using-core-typed/ > apply-map.

There are lots of things core.typed couldn't do back then...

@peter.kehl Good idea to keep that in mind but I don’t think it’s on the horizon for this project.

i’m interested in O(logN) complexity. Are there any guarantees while using subseq?

according to https://github.com/clojure/clojure/blob/clojure-1.9.0/src/clj/clojure/core.clj#L5049 it just applies seq and takes the items while the test is true

ooo but seqFrom appears to be more smart on the collection, interesting