Thank you so much for giving us your light, master of the dotted pair notation ;-)
2009/6/13 Wrexsoul <d2387...@bsnow.net>: > > Now I'm working on some Swing code and came up with these, which are > obviously going to be useful: > > (defmacro do-on-edt [& body] > `(SwingUtilities/invokeLater #(do ~...@body))) > > (defmacro get-on-edt [& body] > `(let [ret# (atom nil)] > (SwingUtilities/invokeLater #(reset! ret# [(do ~...@body)])) > (loop [] > (let [r# @ret#] > (if r# > (first r#) > (recur)))))) > > (defmacro future-on-edt [& body] > `(future (get-on-edt ~...@body))) > > The do-on-edt macro executes its body on the EDT and returns nil. > > The get-on-edt macro does similarly, but returns whatever the body > returns. It blocks until the body has returned, though, which you may > not want, though since it executes on the EDT it should execute fast. > > The future-on-edt macro avoids this blocking behavior. It behaves as > if you scheduled its body to run as a future on the EDT instead of on > whatever thread(s) futures usually run on. In actual fact, the future > it returns is executing the blocking get-on-edt. :) > > Action listener code can assume it will run on the edt, but plenty of > other things do not; notably, REPL expressions do not, as well as > anything explicitly launched into another thread and anything executed > as a result of load-file or via a main class. > > This code, which I offer to the public domain, also furnishes some > simple examples of macro design, as well as of the use of an atom to > move information between threads, plus a recurrence of the one-cell- > vector idiom for having both nil and "meta-nil", distinguishing not- > set-yet from actually-returned-nil. This also showed up in super-lazy- > seq where ultimately one var could end up holding either a boxed > return value or *two* out-of-band values, nil and :skip. (Another > trick for returning out-of-band values is to return a two-element > vector with a value in one cell and an accompanying bit of meta-data > in the other, for example [item found] distinguishing [nil false] from > [nil true]. Other lisps admit of the same trick, using a cons cell > (item . found) for instance, or using nil vs. (item . nil) or any-atom > vs. (item . nil). Don't know if anyone else here is familiar with > dotted-pair notation though, except clojure's author.) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
