The complicated-looking semaphore code was adapted from http://stackoverflow.com/a/5275254/2559313 . I think some issues with other alternatives are in there.
On Mon, Mar 10, 2014 at 1:27 PM, Nikita Beloglazov <nikelandj...@gmail.com>wrote: > 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. > -- 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.
