Hello Nikita, I think Quil should definitely provide a way to write functional style processing code. At the moment, my knowledge of both Clojure and Processing is not enough to evaluate these solutions. I'm certainly going to write my code following some of this and if someone proposes a solution to be part of Quil 2, I would happily adopt it and report back on my experiences.
BTW, I noticed you had some discussions on IRC, you can find me there as Pupeno. On Monday, March 10, 2014 12:29:00 AM UTC, Nikita Beloglazov wrote: > > Hi Pablo > > You can find similar old thread on Quil github repo: > https://github.com/quil/quil/pull/19 It may serve as good background what > other people considered to make Quil more "functional-style". > > I like your suggestion though I would split your :draw function to 2 fns: > an :update function, which only purpose is to update state and :drawwhich > draws state and doesn't change the world at all. If this approach is > implemented - other handler functions like :mouse-move, :key-pressed are > also need to become update-like functions - they should take state as > argument and return new state. > > The only problem is that it is not backward compatible at all. But > probably we still can do it... We can add option :fun-mode? true (stands > for functional-mode) which enables all these changes - :draw takes state > as argument, new :update function is added for modifying state, all > handlers behave like :update. This option is enabled per-sketch. It > requires additional work on Quil internals, but I think it is doable. This > option can be implemented in coming quil 2.0 and it would be great feature > to have. > > One more thing we could do to make it more functional-like - pass > "changed" values to handlers directly. Currently when :key-pressedhandler is > called - no argument is passed to the function and you need to > use (key-code) or (raw-key) functions to identify which key was pressed. > I think this parameters should be explicitly passed to the function. > > What do you think? > > Nikita > > On Sunday, March 9, 2014 1:21:58 PM UTC, J. Pablo Fernández wrote: >> >> >> >> On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote: >>> >>> Hello, >>> >>> To be honest I don't see any fundamental difference between your first >>> attempt and the improvement: both share the fact that the mutation of the >>> state happens within the draw function. So in both cases, you have a >>> temporal coupling between updating the state of the app and rendering a new >>> view of the app's state. >>> >> >> Yes, what's happening in both cases is very similar, but the function >> draw in the "functional" style, in my opinion, is easier to read and maybe >> it's also easier to test. >> >> >>> I would suggest that you don't swap! at all within draw, just deref and >>> render the result of the dereffing. >>> >>> And, in another thread, at potentially a totally different pace than the >>> redrawing's pace, update the application's state accordingly to business >>> rules / constraints. >>> >>> Schematically, something like this: >>> >>> (def app-state (atom (init-state))) >>> >>> (defn draw [...] >>> (let [app-snapshot (deref app-state)] >>> ... call quil primitives to render the application state snapshot >>> ...)) >>> >>> (future >>> ... logic which updates the app-state atom depending on business rules >>> / constraints, in a separate thread ...) >>> >> >> I never worked with future, this is exciting, but I have some questions. >> Do you mean that future is completely separate from draw? I'm just getting >> started, but draw is not only a function to draw, but as a side effect is >> the clock of the app, as it's called according to the set frames per second >> and you normally *take a step* en each draw. Would draw create these >> futures for the next draw? >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
