Re: yet another Clojure snake

2009-01-08 Thread Korny Sietsma
On Fri, Jan 9, 2009 at 7:55 AM, Tom Ayerst wrote: > 2009/1/8 Mark Volkmann >> >> On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: >> > The point, for me, is that Mark Engelberg's construct allowed the system >> > to >> > work with no mutation >> >> I don't yet see how that is possible. > > We

Re: yet another Clojure snake

2009-01-08 Thread Tom Ayerst
2009/1/8 Tom Ayerst > 2009/1/8 Mark Volkmann > >> >> > while cleanly painting the board; the two thread >> > approach flickers terribly when the snake is short. >> >> I could be wrong, but I don't think that flicker is related to my >> choice of doing the painting off the EDT. I think it's just

Re: yet another Clojure snake

2009-01-08 Thread Tom Ayerst
2009/1/8 Mark Volkmann > > On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: > > The point, for me, is that Mark Engelberg's construct allowed the system > to > > work with no mutation > > I don't yet see how that is possible. We agree then. > ... > > Can you explain in more detail the issu

Re: yet another Clojure snake

2009-01-08 Thread Chouser
On Thu, Jan 8, 2009 at 12:05 PM, Tom Ayerst wrote: > The point, for me, is that Mark Engelberg's construct allowed the system to > work with no mutation and I don't think you can do it with Swing implemented > the way it is (your latest version puts the mutation in an atom). Isn't a GUI by defin

Re: yet another Clojure snake

2009-01-08 Thread Mark Volkmann
On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: > The point, for me, is that Mark Engelberg's construct allowed the system to > work with no mutation I don't yet see how that is possible. The detection of key presses has to happen in the Swing thread (by getting a call to keyPressed). That th

Re: yet another Clojure snake

2009-01-08 Thread Tom Ayerst
The point, for me, is that Mark Engelberg's construct allowed the system to work with no mutation and I don't think you can do it with Swing implemented the way it is (your latest version puts the mutation in an atom). Given that, and the problems with to threads accessing the Swing layer, I think

Re: yet another Clojure snake

2009-01-08 Thread Mark Volkmann
On Thu, Jan 8, 2009 at 5:08 AM, Tom Ayerst wrote: > Hi Mark, > > I don't think this approach works in Clojure / Swing, but I may be > mistaken, I often am. > > The issue is the event thread. In Abhishek's original and it's derivatives > the Swing event thread is used and the timer pushes events

Re: yet another Clojure snake

2009-01-08 Thread Tom Ayerst
Hi Mark, I don't think this approach works in Clojure / Swing, but I may be mistaken, I often am. The issue is the event thread. In Abhishek's original and it's derivatives the Swing event thread is used and the timer pushes events into it so key press events and the game timer run in the same

Re: yet another Clojure snake

2009-01-07 Thread Korny Sietsma
As a complete clojure newbie (hi folks!) from a Ruby/Java background, I kind-of don't like either - I'd pull out a named function like: (def add-mix-and-beat [bowl, dry-ingredients wet-ingredients] ... and then use your second example, but now it's: (def make-cookies-2a [flower baking-soda salt

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 3:05 PM, Tom Ayerst wrote: > Honestly? The second one, but I did say I didn't like the 'big let' style, > maybe that is why. I think I may be in the minority on this. I suspect there are more people currently using Clojure who came to it from a Lisp background than a Java

Re: yet another Clojure snake

2009-01-07 Thread Tom Ayerst
Honestly? The second one, but I did say I didn't like the 'big let' style, maybe that is why. Cheers Tom 2009/1/7 Mark Volkmann > > On Wed, Jan 7, 2009 at 3:13 AM, Tom Ayerst wrote: > > Hi Mark, > > > I agree they could be inlined, but I find that style easier to read. > For example, these a

Re: yet another Clojure snake

2009-01-07 Thread Nathan Kitchen
On Jan 7, 7:01 am, "Mark Volkmann" wrote: > On Wed, Jan 7, 2009 at 3:13 AM, Tom Ayerst wrote: > > Hi Mark, > > > I'm afraid I don't like the "big let" style and I found it hard to follow > > some of your code, that may just be a personal thing but a lot of the vars > > defined in let are only us

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 8:52 AM, Christophe Grand wrote: > > Mark Volkmann a écrit : >> I'd >> really like to find a way to get rid of that global variable, but I >> haven't been able to. > You can pass an atom (locally defined in main) to create-panel, and pass > it to your step function. Thanks

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 3:13 AM, Tom Ayerst wrote: > Hi Mark, > > I'm afraid I don't like the "big let" style and I found it hard to follow > some of your code, that may just be a personal thing but a lot of the vars > defined in let are only used once and could be inlined. I agree they could be

Re: yet another Clojure snake

2009-01-07 Thread Christophe Grand
Mark Volkmann a écrit : > I'd > really like to find a way to get rid of that global variable, but I > haven't been able to. You can pass an atom (locally defined in main) to create-panel, and pass it to your step function. Christophe --~--~-~--~~~---~--~~ You re

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 3:13 AM, Tom Ayerst wrote: > Hi Mark, > > I think the def inside a defn has to go, it looks like an accident in waiting. I'm not sure about that. The value last-key-code is only set in the keyPressed method which is invoked when Swing/AWT detects that the user pressed a ke

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 3:13 AM, Tom Ayerst wrote: > Hi Mark, > > I think you are replacing globals with a "god" structure (game) which passed > to every function, I think you need to abstract more. That's definitely what I'm doing and I don't like it either. I just haven't worked out a better al

Re: yet another Clojure snake

2009-01-07 Thread Mark Volkmann
On Wed, Jan 7, 2009 at 12:55 AM, Emeka wrote: > > Hello, > > Why not changing defns create-apple and create-snake to defs create-apple > and snake-create.Your defns have no args that why I feel strongly that they > should def, well I may be wrong. The newest version of my code only has one defn

Re: yet another Clojure snake

2009-01-07 Thread Tom Ayerst
Hi Mark, I think the def inside a defn has to go, it looks like an accident in waiting. I think you are replacing globals with a "god" structure (game) which passed to every function, I think you need to abstract more. I'm afraid I don't like the "big let" style and I found it hard to follow some

Re: yet another Clojure snake

2009-01-06 Thread Emeka
Hello, Why not changing defns create-apple and create-snake to defs create-apple and snake-create.Your defns have no args that why I feel strongly that they should def, well I may be wrong. Emeka --~--~-~--~~~---~--~~ You received this message because you are su

Re: yet another Clojure snake

2009-01-06 Thread Mark Volkmann
On Tue, Jan 6, 2009 at 3:07 PM, Mark Engelberg wrote: > > One way to approach this without mutation is as follows: > > Decide on a data representation that represents the entire state of > the game world at a given instant. > > Write a function which can draw this state. > Write a function which

Re: yet another Clojure snake

2009-01-06 Thread Mark H.
On Jan 6, 1:07 pm, "Mark Engelberg" wrote: > Decide on a data representation that represents the entire state of > the game world at a given instant. > > Write a function which can draw this state. > Write a function which takes the state and player keypresses as input, > and returns a new update

Re: yet another Clojure snake

2009-01-06 Thread Meikel Brandmeyer
Hi, Am 07.01.2009 um 00:18 schrieb Tom Ayerst: There is a bug in end-game? which means it never ends. I'm not sure if this is the most idiomatic way to fix it but it seems to work. (defn end-game? [{:keys [apple snake]}] The idiomatic way is maybe using :as. (defn end-game? [{:keys [appl

Re: yet another Clojure snake

2009-01-06 Thread Tom Ayerst
What is interesting to me (and as it should be, I guess) is that as the code gets more 'functional', it gets easier to work with, which is nice. Cheers Tom 2009/1/6 Rich Hickey > > On Tue, Jan 6, 2009 at 2:07 PM, Stuart Halloway > wrote: > > > > Hi Rich, > > > > Thanks for the suggestion. I h

Re: yet another Clojure snake

2009-01-06 Thread Tom Ayerst
Hi Stuart, There is a bug in end-game? which means it never ends. I'm not sure if this is the most idiomatic way to fix it but it seems to work. < (defn end-game? [{:keys [apple snake]}] < (cond < (lose? snake) (do (reset-game) "You lose!") < (win? snake) (do (reset-game) "You win!")))

Re: yet another Clojure snake

2009-01-06 Thread Stuart Halloway
> also, i assume doing this efficiently relies on having immutable data > structures that are properly optimized to share whatever they need to > rather than having needless copy operations? Right. Clojure's data structures all designed with this in mind, and do not do needless copying. Stuart

Re: yet another Clojure snake

2009-01-06 Thread Stuart Halloway
Is this the snake monad? :-) Stuart > One way to approach this without mutation is as follows: > > Decide on a data representation that represents the entire state of > the game world at a given instant. > > Write a function which can draw this state. > Write a function which takes the state and

Re: yet another Clojure snake

2009-01-06 Thread Raoul Duke
> This is an outline of the strategy employed by the "world" teachpack > that accompanies the "How to Design Programs" curriculum that uses PLT > Scheme. Students routinely develop the snake program as a homework > assignment, using this approach. +1 / word up / hear hear. also, it is akin to u

Re: yet another Clojure snake

2009-01-06 Thread Mark Engelberg
One way to approach this without mutation is as follows: Decide on a data representation that represents the entire state of the game world at a given instant. Write a function which can draw this state. Write a function which takes the state and player keypresses as input, and returns a new upd

Re: yet another Clojure snake

2009-01-06 Thread Rich Hickey
On Tue, Jan 6, 2009 at 2:07 PM, Stuart Halloway wrote: > > Hi Rich, > > Thanks for the suggestion. I have moved all the per-game stuff (apple, > snake, frame, panel, and timer) into a local let inside a game > function. Is that what you had in mind? > Yup. Rich > >> On Jan 6, 11:54 am, Stuart

Re: yet another Clojure snake

2009-01-06 Thread Stuart Halloway
Hi Rich, Thanks for the suggestion. I have moved all the per-game stuff (apple, snake, frame, panel, and timer) into a local let inside a game function. Is that what you had in mind? Stuart > On Jan 6, 11:54 am, Stuart Halloway wrote: >>> Code like @*foo* is not something I've seen in any

Re: yet another Clojure snake

2009-01-06 Thread Chouser
On Tue, Jan 6, 2009 at 11:54 AM, Stuart Halloway wrote: > >> Code like @*foo* is not something I've seen in any code Rich has >> written, so I think Stuart is right in considering removing the >> asterisks on *apple* and *snake* > > I plan to remove them. What I still wrestle with is using "snake

Re: yet another Clojure snake

2009-01-06 Thread Rich Hickey
On Jan 6, 11:54 am, Stuart Halloway wrote: > > Code like @*foo* is not something I've seen in any code Rich has > > written, so I think Stuart is right in considering removing the > > asterisks on *apple* and *snake* > > I plan to remove them. What I still wrestle with is using "snake" at > the

Re: yet another Clojure snake

2009-01-06 Thread Stuart Halloway
> Code like @*foo* is not something I've seen in any code Rich has > written, so I think Stuart is right in considering removing the > asterisks on *apple* and *snake* I plan to remove them. What I still wrestle with is using "snake" at the top level as ref, and then having a bunch of pure func

Re: yet another Clojure snake

2009-01-06 Thread Mark H.
On Jan 6, 7:18 am, "Mark Volkmann" wrote: > I wish there was a convention for identifying constants in Clojure, > even if it's not enforced. I'd be fine with making their names all > uppercase as in Java, but I'm open to other suggestions. The naming convention in Common Lisp for constants is +

Re: yet another Clojure snake

2009-01-06 Thread Chouser
On Tue, Jan 6, 2009 at 11:28 AM, Mark Volkmann wrote: > > On Tue, Jan 6, 2009 at 9:00 AM, Stuart Halloway > wrote: >> >> I like to use the *form* for names that might be dynamically rebound. >> Thinking about removing them from snake and apple as well. > > Based on the reply from Chouser, I thin

Re: yet another Clojure snake

2009-01-06 Thread Mark Volkmann
On Tue, Jan 6, 2009 at 9:00 AM, Stuart Halloway wrote: > >> I'm curious why you decided not to surround the names of constants >> with asterisks. I see you did use asterisks around snake and apple. >> I'm still confused about whether there's a convention for that. > > I like to use the *form* for

Re: yet another Clojure snake

2009-01-06 Thread Mark Volkmann
On Tue, Jan 6, 2009 at 9:29 AM, Chouser wrote: > > On Tue, Jan 6, 2009 at 10:18 AM, Mark Volkmann > wrote: >> >> I wish there was a convention for identifying constants in Clojure, >> even if it's not enforced. I'd be fine with making their names all >> uppercase as in Java, but I'm open to othe

Re: yet another Clojure snake

2009-01-06 Thread Chouser
On Tue, Jan 6, 2009 at 10:18 AM, Mark Volkmann wrote: > > I wish there was a convention for identifying constants in Clojure, > even if it's not enforced. I'd be fine with making their names all > uppercase as in Java, but I'm open to other suggestions. Vars are correctly used only two ways, are

Re: yet another Clojure snake

2009-01-06 Thread Mark Volkmann
On Tue, Jan 6, 2009 at 9:00 AM, Stuart Halloway wrote: > >> I'm curious why you decided not to surround the names of constants >> with asterisks. I see you did use asterisks around snake and apple. >> I'm still confused about whether there's a convention for that. > > I like to use the *form* for

Re: yet another Clojure snake

2009-01-06 Thread Stuart Halloway
> I see you didn't override getPreferredSize in your JPanel proxy and > instead call setSize on the JFrame. When I did that I found that the > size included the JFrame title bar. That meant that the usable area > wasn't as tall as what I wanted. That's why I decided to size the > panel instead and

Re: yet another Clojure snake

2009-01-06 Thread Tom Ayerst
Hi, I hope you don't mind, rather than comment on the code I made some changes (many lifted from Abhishek and Mark's implementation): add-points only creates one point and it doesn't move anything so name should change, suggest new-point (maybe new-head as it is always used by the snake?) def

Re: yet another Clojure snake

2009-01-05 Thread Mark Volkmann
On Mon, Jan 5, 2009 at 2:54 PM, Stuart Halloway wrote: > > Since there has been so much back-and-forth about the Clojure snake, I > decided to write one [1]. Like Mark, my goal is to create a readable > version, but the details are quite different. > > I plan to use this as the code example for t

Re: yet another Clojure snake

2009-01-05 Thread Fanda
PS: Sometimes the apple is too close to the edge or not seen at all. Might need to adjust apple position generation. On Jan 5, 10:26 pm, Fanda wrote: > Nice use of 'import-static' and multimethods for 'paint' ;-) > > Personally, I would move (def timer (Timer. turn-millis panel)) to the > end:

Re: yet another Clojure snake

2009-01-05 Thread Fanda
Nice use of 'import-static' and multimethods for 'paint' ;-) Personally, I would move (def timer (Timer. turn-millis panel)) to the end: (doto panel (.setFocusable true) (.addKeyListener panel)) (doto frame (.add panel) (.setSize (* width point-size) (* height point-size)) (.setVisibl

Re: yet another Clojure snake

2009-01-05 Thread Chouser
On Mon, Jan 5, 2009 at 3:54 PM, Stuart Halloway wrote: > > Since there has been so much back-and-forth about the Clojure snake, I > decided to write one [1]. Like Mark, my goal is to create a readable > version, but the details are quite different. > > I plan to use this as the code example for t

yet another Clojure snake

2009-01-05 Thread Stuart Halloway
Since there has been so much back-and-forth about the Clojure snake, I decided to write one [1]. Like Mark, my goal is to create a readable version, but the details are quite different. I plan to use this as the code example for the Swing section in the book. Feedback welcome. Stuart [1]