On Sat, Aug 27, 2011 at 10:24 AM, Brian Goslinga
wrote:
> For example, is this piece of code legal?
> (let [x 5]
> (* x 2))
> Currently it is. However, if we restricted the shadowing of locals, it
> may or may not be -- you cannot tell unless you look at the
> surrounding context.
So, the restri
On Sat, Aug 27, 2011 at 6:05 AM, Alan Malloy wrote:
> Stylistically, it's often not very nice to rebind x a number of times;
> it's better to choose descriptive names for the intermediate steps.
> But there are certainly times occasions where using the same name can
> clarify meaning: for example,
Hi Terje,
The `let` form allows rebinding of symbols, which is not the same as
mutability. In the form
(let [x 1
y 2
x (+ x y)]
x)
the value of `x` does not change, rather the third line creates a new
binding for `x`. The difference may seem trivial, but most func
On Aug 27, 4:37 am, Terje Dahl wrote:
> I was surprised to discover that the following was possible:
>
> (let [
> x 1
> y 2
> x (+ x y) ]
> x )
>
> This runs and returns 3!
>
> This feels an awful lot like variables and procedural programming.
> It is left up to the devel
Perhaps you'd be more comfortable considering this equivalent syntax:
(let [x 1]
(let [y 2]
(let [x (+ x y)]
x)))
In principle, the multiple-binding let is transformed to this version
and thus has identical semantics; in practice, the compiler does
something more efficient but equival
On 15 Jan, 17:40, Laurent PETIT wrote:
> Simon,
>
> To be very clear, and incite you to watch all those videos and read
> all this material:
>
> One of the key motivations (if not the primary) of Rich writing
> clojure has been constructing a language which would offer built-in
> semantics to mana
On Fri, Jan 15, 2010 at 7:58 AM, ataggart wrote:
> And a neat series showing how games which look imperative can be bent
> to be (mostly) functional:
> http://prog21.dadgum.com/23.html
i find it interesting that there are so many drastically different
approaches cf. http://world.cs.brown.edu/
si
Simon,
To be very clear, and incite you to watch all those videos and read
all this material:
One of the key motivations (if not the primary) of Rich writing
clojure has been constructing a language which would offer built-in
semantics to manage state change over time.
So you're really in the ri
Also check out Rich's video covering concurrency, and in particular
his Ants program:
http://blip.tv/file/812787
For more on state stuff:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
And a neat series showing how games which look imperative can be bent
to be (mostly) functional
Hi,
On Jan 15, 4:25 pm, Simon Brooke wrote:
> Right, I'm trying to get my head around the consequences of
> Opinions?
You have to distinguish between identity and state.
Disclaimer: I have no clue whatsoever about game design.
The different rooms are identities, the different players are
iden
On Jan 15, 7:25 am, Simon Brooke wrote:
> So, there seem to be four possibilities
>
> (1) I've chosen the wrong language for the problem, or vice versa;
> (2) There is some idiomatic means of managing mutable state which I've
> missed;
> (3) The right solution is to create a hybrid system using
I've finished my MUD - 240 lines including blanks and comments
http://clojure.googlegroups.com/web/funmud.clj
http://clojure.googlegroups.com/web/funmud.PNG
Obviously it is in no way comparable as mine is a PvP whereas the OP
was a single player (not really a Multi User Dungeon you know!).
Anywa
I've implement a basic chat server application (as a stepping stone to
bigger things).
Simply run up the server eg: clj server.clj
then use telnet to connect: telnet localhost
connect from another window, and start typing messages to yourself...
You'll see it relays the chat messages ar
I added the project in google code (github kept complaining about my
public key)
http://code.google.com/p/randomrpg/
I reduced the LOC to ~900.
I'll try once more to port it to clojure (thanks for the macro Adam),
but don't know when i'll be done.
Regards.
Islon
On Nov 21, 4:27 pm, Adam Jones <
On Nov 20, 12:23 pm, islon <[EMAIL PROTECTED]> wrote:
> I'm porting my single thread simple mud-like rpg game from scala to
> clojure and one thing that is annoying me is the code needed to change
> some var.
> In scala I do things like that:
>
> val player = new Player(...)
>
> player.str += 1
There's no problem with clojure, the problem is with me: I'm a
complete noob in clojure programming =)
That's why I asked if anyone wanted to port the game. I'll probably
learn more reading someone's idiomatic code than my own bad code.
I started this project to learn scala so the final code could
> Step right up folks and place your bet.
Depends on the implementer, Chouser can do it in 95 LOC
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@google
It would be interesting to see how many lines a 1000 LOC Scala
projects translates into idiomatic clojure clode.
Step right up folks and place your bet.
Without knowing anything about Scala or the project in particular, I'm
guessing ~750. Any other takers?
On Thu, Nov 20, 2008 at 11:31 PM, Paul
Sure, I'd be interested in porting it, would give me a reason to learn
Scala :). Just post the code to github or something and let us know
where it's at.
On Nov 20, 10:42 pm, islon <[EMAIL PROTECTED]> wrote:
> I gave up, the resulting code would be a lot more complex than the
> scala version.
>
I must be missing something. Even if you have to make every
modification inside a dosync using the syntax that you originally
provided, why not write a function that captures that and be done with
it? Or, if you have to, a macro? That is, it seems like the complaint
is "too much repeated code", bu
I gave up, the resulting code would be a lot more complex than the
scala version.
But thanks for your advices.
If anyone wants to port it I can send the source code, it's ~1000
lines total.
Islon
On Nov 20, 11:38 pm, harrison clarke <[EMAIL PROTECTED]> wrote:
> i was thinking that each stat wou
i was thinking that each stat would be an agent.
whatever boats your float, i guess. i'm probably not the person to go
to about idiomatic code. :V
user> (let [player {:str (agent 5)
:dex (agent 5)}
str (:str player)
dex (:dex player)]
(println @str @dex)
(send str +
On Thu, Nov 20, 2008 at 8:51 PM, islon <[EMAIL PROTECTED]> wrote:
>
> Thanks for the ideas =)
> I'll use agents to represent state (I don't know how I forgot it,
> thanks Harrison), they are a lot more concise than refs and make a lot
> more sense in my context.
> Only one problem:
>
> user=> (def
Thanks for the ideas =)
I'll use agents to represent state (I don't know how I forgot it,
thanks Harrison), they are a lot more concise than refs and make a lot
more sense in my context.
Only one problem:
user=> (def player (agent {:str 2 :dex 3}))
#=(var user/player)
user=> @player
{:str 2, :dex
Given that is the correct way to mutate state, why do we need so much
explicit syntax?
user=> (defn += [a b c] (dosync (commute a update-in [b] #(+ c %1
user=> (+= player :str 1)
{:str 56}
; are you a giant?
Ok so if I did something like this:
(+= player :int 5)
(+= player :hpmax 10)
in one
> (send (:str player) #(+ % 1))
on second thought, this should be the same:
(send (:str player) + 1)
or:
(send (player :str) + 1)
if you use agents, just make sure you use await before dereferencing
them. could cause some issuses if you don't.
--~--~-~--~~~---~--~---
i think agents would be a better fit than refs.
as you said, you don't need transactions, since everything is sequential
anyway.
so whenever you need to change something, just send the change to the agent.
(send (:str player) #(+ % 1))
--~--~-~--~~~---~--~~
You r
On Thu, Nov 20, 2008 at 4:16 PM, islon <[EMAIL PROTECTED]> wrote:
>
> if you are a 100% sure that
> your program is singlethreaded and will never
> be multithread it's annoying all the ceremony to set a variable.
There are ways out of the box, if you want to get dirty. You can just
call (def foo
Thanks Chouser.
Just to clarify some points:
I'm not saying scala ir better than clojure or clojure is bad or
immutability is a bad thing, and I know that a true game is
multithread (I'm a game programmer).
Clojure forces you to program in a thread safe way and it's a good
thing when you are doin
On Thu, Nov 20, 2008 at 3:23 PM, islon <[EMAIL PROTECTED]> wrote:
>
> in clojure I have to do (player is a struct and its attributes are
> refs):
>
> (def player (Player ...))
>
> (dosync (ref-set player (assoc player :str (inc (:str player)
Assuming you meant:
(def player (ref {:str 55}))
(d
30 matches
Mail list logo
