> >I think that's correct (with the exception you already mention yourself:
> >you can use a :state structure containing multiple values).
>
> OK.
If you care mostly about performance, maybe using an array as :state
> will do. That's always mutable and access is really fast.
>
Oh, nice id
Mars0i writes:
> Is the following correct?
>
> The only way to define *multiple* mutable instance variables/fields
> for a class visible in Java is by using deftype with :volatile-mutable
> or :unsynchronized-mutable. The only way to inherit from a concrete
> Java class is by using gen-class or
Thanks--you're right, of course, Marshall. (I almost added "without
writing it in Java" somewhere in the first part of the post. That doesn't
mean writing parts in Java isn't worth considering. I'm just trying to
figure out what will and won't work in Clojure itself.)
-Marshall
On Wednesday
Mars0i writes:
> I believe these statements are correct, but gen-class is complex and
> deftype use has some nuances, so I want to make sure I haven't missed
> something.
You have missed one possible approach – write a small integration class
in Java which delegates behavior to a parameterized s
Is the following correct?
The only way to define *multiple* mutable instance variables/fields for a
class visible in Java is by using deftype with :volatile-mutable or
:unsynchronized-mutable.
The only way to inherit from a concrete Java class is by using gen-class or
proxy. gen-class allows a
On Fri, Jun 7, 2013 at 9:28 PM, Gary Trakhman wrote:
> sounds fun, have you seen this yet?
>
>
> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>
wicked cool
thx
I'll do this then :
(deftype Foo [^{:volatile-mutable true} x]
Object
(setBar [thi
sounds fun, have you seen this yet?
http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
On Fri, Jun 7, 2013 at 3:21 PM, Denis Labaye wrote:
> Hi,
>
> I'm writting Clojure code that is used by a Java framework (Fitnesse's
> slim for those who knows).
>
Hi,
I'm writting Clojure code that is used by a Java framework (Fitnesse's slim
for those who knows).
To workflow is like this:
Instanciation of a new Java objectf = new Foo()Initialization with
settersf.setBar("ze
bar")And then call some methodsf.baz()
My solution is something like:
(ns Foo
In general, def* forms are not supposed to be nested, although it does work
for cases like this.
In my limited use of ClojureScript so far, I've gotten over problems like
this by having an initialization function, at the bottom of my source file,
that sets up global state like loggers.
-S
--
I'd like to use clojurescript to set up a gclosure logger
(goog.debug.Logger) similar to the closure demo [1]. The slightly
modified javascript for this is below. How should clojurescript
insulate the programmer from the mutability issues?
1) log level mutates a LogManager object
2) a logco
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
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
f immutability holds, anyone
reading your code can easily "fold up" all the x-related expressions,
into (let [x (* 2 (inc 1))] x). The same would *not* be true if real
mutability were happening, as with a Java for loop, because statements
could be executed multiple times with different
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 developer to not resetting a "variable" - by
convention - and if
2010/1/16 Simon Brooke :
> general case of a cyclic directed graph. Surely there must be some
> clean idiomatic way of creating a cyclic graph?
I experimented with something very similar when I first encountered Clojure:
http://clojure.googlegroups.com/web/funmud.clj
And ended up representing the
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
Right, I'm trying to get my head around the consequences of
immutability for the sort of programming practices I'm used to, and
how I change the way I do things to fit in with it. Initially I
thought 'well, immutability just means you can't use rplaca and
rplacd, and I've very rarely used either so
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
; > some var.
> > In scala I do things like that:
>
> > val player = new Player(...)
>
> > player.str += 1
>
> > in clojure I have to do (player is a struct and its attributes are
> > refs):
>
> > (def player (Player ...))
>
> > (dosync (ref-set
ayer(...)
>
> player.str += 1
>
> 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)
>
> In scala when I want mutability I just define the v
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
strictly needed, but that
is just my opinion.
I miss some easy way to do mutability and object orientation, but
otherwise clojure is great =)
Islon
On 20 nov, 17:38, Chouser <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 3:23 PM, islon <[EMAIL PROTECTED]> wrote:
>
> >
:
(def player (ref {:str 55}))
(dosync (ref-set player (assoc @player :str (inc (:str @player)
This could be written:
(dosync (commute player update-in [:str] inc))
This is somewhat shorter, but also handles more deeply-nested structures easily.
> In scala when I want mutability I just
s are
refs):
(def player (Player ...))
(dosync (ref-set player (assoc player :str (inc (:str player)
In scala when I want mutability I just define the variable with "var"
instead of "val", just one letter, simple and elegant.
It's a game, it's full of states and mu
44 matches
Mail list logo
