Lee, I think question about managing/updating state in quil pop ups pretty frequently and many people expect quil to have built-in tools to do it in functional style. And using atoms to update state may feel hacky. I think this tools should exist and quil 2.0 is a good time to address the issue. Yes, Pablo's and mine changes are cosmetic but still they will help to feel functional nature of quil and I think it is a win. As for translating Processing code to Quil - I think it's already not very easy for people who has little experience with functional programming and therefore I don't think these cosmetic changes will add much complexity.
The only issue I see, which is you mentioned, is having two similar but still separate modes. It may create confusion for newcomers. Though I will be glad to hear other opinions on the question and see if people generally like the idea or would rather keep old good quil as it is. Gary, Thank you. It might be useful in future if we decide to implement similar thing. Thank you, Nikita On Mon, Mar 10, 2014 at 4:27 AM, Gary Trakhman <gary.trakh...@gmail.com>wrote: > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/UQ3iPC6Oj9g/unsubscribe. > To unsubscribe from this group and all its topics, 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.
