FWIW, I've got an example of a decoupled update/draw loop here: https://github.com/gtrak/quilltest/blob/master/src/quilltest/balls.clj
On Sun, Mar 9, 2014 at 10:16 PM, Lee Spector <lspec...@hampshire.edu> wrote: > > FWIW I'm not crazy about these suggestions because they seem to me to be > mostly cosmetic, and actually negative if they end up leading to multiple > incompatible modes of operation. The Processing model seems to me to be > intrinsically imperative, and it's also well-known by lots of people and > easy to understand. The current Quil scheme, which provides fairly direct > access to Processing's existing model from Clojure, still allows us to > write functional-style code for all of the interesting stuff that we do > within/between calls to the imperative Processing calls. And it allows one > to translate Processing ideas into Quil relatively easily. So I like it > like it is :-). > > -Lee > > On Mar 9, 2014, at 8:29 PM, 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 :draw > which 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-pressed handler > 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 > > -- > 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. > -- 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.
