On Mon, 2012-03-19 at 03:56 -0700, Narvius wrote:
> 2) Return [new-state success?] instead of just new-state - requires too
> much acrobatics from the user of the function (which is still me, but
> whatever).
Don't be so sure...you can arrange for values "on the side" to be
readable and writable
Alright.
1) Why I need success state: this is a turn-based game, and I want to
advance the world clock if and only if the player makes a valid move.
2) identical? makes sense. I generated some unnecessarily large data
structure and checked, it really is ridiculously fast. Thanks!
3) Returning ni
On Mar 19, 3:56 am, Narvius wrote:
> I am writing a game in Clojure, and I often need some functions to return
> whether they succeeded in doing what they are supposed to do
>
> []
>
> I see several ways to achieve what I want, that is to return both the new
> world state and success status.
>
On Mon, Mar 19, 2012 at 7:14 PM, jk wrote:
> I read this and wondered why you care? Isn't it sufficient to return
> the new world state? You could use identical? as someone suggested but
> why bother? It sounds like the player should be able to keep bumping
> into the wall if they keep making the
On Mar 19, 2012, at 5:31 PM, Michael Gardner wrote:
> Or the simplest option: just have your functions return nil to indicate that
> the world state should remain unchanged from its previous value.
If your world state is a hash-map, you could also return partial states and
merge them into the e
On Mon, Mar 19, 2012 at 3:56 AM, Narvius wrote:
> I see several ways to achieve what I want, that is to return both the new
> world state and success status.
> 1) Compare the old and new value - doesn't seem very efficient.
>
Probably not as inefficient as you think. Identical things are recogn
I read this and wondered why you care? Isn't it sufficient to return
the new world state? You could use identical? as someone suggested but
why bother? It sounds like the player should be able to keep bumping
into the wall if they keep making the same move.
I am just curious why the problem is mor
On Mon, Mar 19, 2012 at 3:56 AM, Narvius wrote:
> 2) Return [new-state success?] instead of just new-state - requires too much
> acrobatics from the user of the function (which is still me, but whatever).
Destructuring makes it easy to work with multi-value returns:
(let [[state status] (make-mo
Hi,
Am Montag, 19. März 2012 11:56:28 UTC+1 schrieb Narvius:
>
> 1) Compare the old and new value - doesn't seem very efficient.
>
>
Just return the very same world state object? You can easily and insanely
fast decide whether it was changed by virtue of "identical?". Then you
don't need any spe
I liked approach 2 myself, if the goal is to stick with pure functions when it
isn't too difficult. It avoids the comparison of 1, and gets you back exactly
the info you want to go onwards from there.
You can add a caveat that I haven't written a lot of application code with
Clojure, so weight
If the success/failure of the function makes sense to represent in game-world
terms, you could encode the information in the world object, perhaps as a flag
that can be attached to the relevant object. In your example, the unit might be
given a "state" with the value :blocked, indicating that so
I am writing a game in Clojure, and I often need some functions to return
whether they succeeded in doing what they are supposed to do (for example,
moving that unit one field to the left may fail due to... I don't know, a
wall?).
But if there is one thing I really like about LISPs is the idea
12 matches
Mail list logo
