Thanks for the interest! :) When it comes to arrows, from what I have read, functions can be seen as a subset to arrows. Although, I don't have sufficient understanding to what this really means.
It's true that standard functions could be used, and would be clearer. I'm a little scared of doing that because people might use the mindset they have of functions and apply it on these "arrows". I don't know if that's really a bad thing though (probably not). I'm currently investigating how extend-type could be used to extend "component-p" which would mean that java objects could be used directly. This would play better with both java and seesaw. ______ Actually, while I'm writing this, I have changed the arrow implementation. Datatypes implementing the arrow protocol only have to implement >>>_int (for internal) and fst_int. I added implementation for functions. >>> and <<< supports any number (> 0) of arrows. https://github.com/odyssomay/Hafni/blob/master/src/Hafni/arrow.clj Jonathan On Thu, Jun 23, 2011 at 5:44 PM, Dave Ray <dave...@gmail.com> wrote: > Hi, > > This looks pretty cool. I'd love to see a larger example of how you'd > apply arrows to managing UI state. From my limited understanding, > functions are arrows, but arrows are not functions. The examples you > give fall pretty much in the "functions are arrows" camp, meaning that > the code could be written just as easily, and maybe more clearly, by > chainging pure functions (please correct me if I'm wrong). I'd like to > see an example where FRP clearly makes handling change easier and more > functional. > > When I started working on Seesaw, I did some reading on FRP, but > decided I was already up to my neck with learning Clojure. As a > result, Seesaw's nice to use, but isn't particularly functional and, > as you say, the most annoying parts are those that manipulate the UI. > So, I'd also like to explore how Hafni could be used in conjunction > with Seesaw. If you have further ideas on this or need help, feel free > to contact me. > > ... and don't feel too bad about writing "another Swing wrapper". A > month after starting Seesaw, I stumbled upon another, abandoned > Clojure+Swing project called ... wait for it... Seesaw. Go figure :) > > Best regards, > > Dave > > On Mon, Jun 20, 2011 at 7:57 AM, Jonathan Fischer Friberg > <odysso...@gmail.com> wrote: > > Hi, > > > > I figured that I would announce a library that I have been working on for > a > > while now. > > > > It's called Hafni, and it's a swing wrapper. Why another swing wrapper? > > I wanted to solve the following problems: > > > > 1. There are a lot of boilerplate code needed. > > > > 2. Changes made to content is not very functional. > > > > 3. Changing content is (sometimes) annoyingly hard. > > > > To solve these problems, I looked into the very functional world of > Haskell > > and found something called Functional reactive programming (FRP)[1][2] > which > > has been used to solve problem 2 in gui programming for Haskell. To be > able > > to program FRP, the datatype "arrow" was created (or maybe the other way > > around), and this is what Hafni uses. I wont go into detail here since it > is > > not very easy to explain in a short mail, and there are a lot of > resources > > out there on the subject (see the links). > > > > To be honest, when I first started programming on Hafni, I didn't know > that > > there existed other swing wrappers for java (I guess I also wanted to try > > this myself, which meant that I didn't really search it out), but since > they > > do exist, lets compare Hafni to the two I have seen on this mailing list: > > seesaw [3] and GUIFTW [4]. > > > > 1. Hafni is strictly a swing wrapper and does not claim to be anything > else. > > Seesaw - aims to provide a ui library, "It happens to be built on > Swing". > > GUIFTW - "It's not tied to any GUI toolkit but instead front-ends for > > each can be written easily." > > > > 2. Hafni has facilities, but is not really interested in exactly how > > components look. > > Seesaw - Doesn't really express an opinion about this, but seems to > have > > a lot of facilities for making components look a certain way. > > GUIFTW - "Style it in a CSS fashion" > > > > 3. When events happen, Hafni uses the "Event" and "arrow" datatypes to > make > > things happen while both > > seesaw and GUIFTW uses something that looks like > > the standard java event function(s). It should be noted that Hafni > > event/arrows > > behaves exactly like corresponding for seesaw and GUIFTW if no changes > is > > made to content. > > > > The reason of 2 (which, in a way, leads to 3) is that when I wrote swing > > code manually, the parts > > that I were most annoyed with weren't to make things look as I wanted > them, > > it was changing them. > > > > I haven't really looked into it exactly (or tried it), but it looks like > > seesaw and Hafni can be combined > > since seesaw deals directly with java objects (the "config!" function is > > especially interesting) [5]. > > > > I would like to end this mail with an example of Hafni. This example is > the > > same as in the Hafni readme. > > > > (frame :content (comp-and-events (button :text "*") > > :act (flow (output-arr this :text) >>> > > (arr #(str % "*")) >>> > > (input-arr this :text))) > > :size 200 200 :dont_exit_on_close) > > > > As it's already explained in the readme, let's look at the most > interesting > > part: > > > > (flow (output-arr this :text) >>> (arr #(str % "*")) >>> (input-arr this > > :text)) > > > > This code snippet says that the current text of the button created with > > (button :text "*") should "flow" to > > the function #(str % "*") which adds a "*" to the text, which should flow > to > > the text of that same button. > > The result of this is that when the button is pressed, the text of that > > button is changed as follows: > > "*" > > "**" > > "***" > > "****" > > etc ... > > > > And finally, the link to Hafni: https://github.com/odyssomay/Hafni > > > > ___________________ > > > > I really hope that someone finds this project interesting, and at best > even > > useful. ;) > > > > Questions, comments, ideas, critique? > > > > Jonathan > > > > 1. http://en.wikipedia.org/wiki/Functional_reactive_programming > > 2. http://www.haskell.org/haskellwiki/Functional_Reactive_Programming > > 3. https://github.com/daveray/seesaw > > 4. https://github.com/santamon/GUIFTW > > 5. > http://daveray.github.com/seesaw/seesaw.core-api.html#seesaw.core/config! > > > > Additional links: > > http://www.haskell.org/haskellwiki/Arrow > > http://en.wikibooks.org/wiki/Haskell/Understanding_arrows > > http://www.haskell.org/arrows/ > > > > > > -- > > 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 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 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
