If you speak German, I have a free book on Clojure (Funktionale
Programmierung in Clojure) for you:
http://denkspuren.blogspot.de/2013/04/freies-clojure-buch-funktionale.html
Dominikus
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
to multimethods.
If you like, enjoy reading my blogpost on The root of polymorphism: The
Anti-If Campaign. It might be an interesting read for Clojure enthusiasts.
http://denkspuren.blogspot.de/2012/05/root-of-polymorphism-anti-if-campaign.html
Cheers,
Dominikus
--
You received this message
it!?
Dominikus
--
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
Sure? The semantics of the default value corresponds to a 'if', doesn't it?
From this viewpoint, the default value is in tail position. And why does
the non-tailrecursive version not run as expected?
Dominikus
Am Freitag, 27. April 2012 16:45:44 UTC+2 schrieb Meikel Brandmeyer
(kotarak
I got it, guys! Thanks a lot! This non-tailrecursive version works as
intended:
(defn fix2 [f x] (let [y (f x)] (eval ({x x} y (list 'fix2 f y)
Dominikus
Am Freitag, 27. April 2012 17:00:52 UTC+2 schrieb Luke VanderHart:
Using a map instead of if means that it is evaluated as a function
://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics
However (type (- 2 1N)) results in java.lang.Long and does not seem to
work accordingly. What's going on here?
Cheers,
Dominikus
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group
integer overflow
clojure.lang.Numbers.throwIntOverflow (Num
bers.java:1374)
The optimization to using Longs seems to be too aggressive. Upgrade
casting in Clojure 1.2 is cool and simple.
Dominikus
On Sep 8, 1:30 pm, Eric Lavigne lavigne.e...@gmail.com wrote:
You have discovered a very recent change
overflow
clojure.lang.Numbers.throwIntOverflow (Num
bers.java:1374)
Weird!
Dominikus
On Sep 8, 2:05 pm, Meikel Brandmeyer (kotarak) m...@kotka.de
wrote:
Hi,
Am Donnerstag, 8. September 2011 13:57:49 UTC+2 schrieb Dominikus:
Upgrade casting in Clojure 1.2 is cool and simple.
It's also
Thanks for the explanation, Meikel!
I'll wait for the next release which hopefully fixes the bug.
Cheers,
Dominikus
On Sep 8, 2:31 pm, Meikel Brandmeyer (kotarak) m...@kotka.de
wrote:
Hi,
Am Donnerstag, 8. September 2011 14:21:09 UTC+2 schrieb Dominikus:
Right, this feature
with an earlier timestamp.
/quote
That's why the second transaction, which comes later in time, is the
one waiting for the first transaction to complete.
Dominikus
On Aug 30, 9:53 am, Laurent PETIT laurent.pe...@gmail.com wrote:
2011/8/30 Kevin Downey redc...@gmail.com
the two threads race to acquire
That's a cool link and an interesting read! Thanks, Stefan!
Dominikus
On Sep 5, 10:23 pm, Stefan Kamphausen ska2...@googlemail.com wrote:
Hi,
there is another paper in the wild which very nicely describes, how
Clojure's implementation of STM works and how it compares to other
management
in-transaction before committing them, a
write-lock shouldn't be needed. I'm surprised, that the second
transaction is the one who has to retry 71 times even though the first
transaction hasn't committed anything yet.
Cheers,
Dominikus
P.S.: Thanks for the idea to use 'future' to spawn a thread!
On Aug 29
representation to compare equal.
Adam
Right, Adam. As Armando pointed out, Clojure 1.3 at least doesn't fail
in the case I brought up. I would be very interested to learn what has
changed in the Clojure 1.3 source code (compared to 1.2) to achieve
this.
Dominikus
--
You received this message because you
@53797795 7)
user= (eval (id 7))
(#user$id user$id@2de12f6d 7)
Consequently, the following comparison leads to false:
user= (= (id 7) (eval (id 7)))
false
Why is the instance relevant to '='? What is the precise semantics of
two values being equal in Clojure?
Dominikus
(Remark: In Scheme, the use
Thanks a lot, Armando. Looks like I should switch to Clojure 1.3 asap.
Cheers,
Dominikus
2011/5/5 Armando Blancas armando_blan...@yahoo.com:
In 1.3 the function will (eval) to itself:
Clojure 1.3.0-alpha6
user= (defn id [x] (list id x))
#'user/id
user= (id 7)
(#user$id user$id@3411a 7
Thanks for the pointers to the implementation, Jonathan!
Unfortunately, I couldnt' find out yet, which part of the source code
in Clojure 1.3 is responsible for fixing the misbehavior in 1.2. The
parts you point to haven't changed in 1.3.
Cheers,
Dominikus
On May 5, 4:27 pm, Jonathan Fischer
that's the issue here. Possibly, some code is missing covering
your case.
Interestingly, macroexpand does not work on your qqq-macro either:
user= (macroexpand '((qqq) (even? 42) boo!))
((qqq) (even? 42) boo!)
That's weird.
Dominikus
On 15 Mrz., 01:24, Ken Wesson kwess...@gmail.com wrote:
On Mon
, it's
dangerous to redefine special forms. Here, I'm interested in the
evaluation strategy of special forms vs. bound symbols.)
Cheers,
Dominikus
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
it?
I come up with this scenario in order to understand the precise
behavior of Clojure's evaluation strategy regarding symbol bindings
and special forms. As I said, I'm fully aware that it's no good idea
to change 'if' or any other special forms in production code.
Dominikus
On 14 Mrz., 18:26
special symbols like 'if' to values at all. I guess that some few
lines in Compiler.java could fix that. I don't know how Lisp treats
this case.
Dominikus
On 14 Mrz., 22:09, Timothy Baldridge tbaldri...@gmail.com wrote:
Yes, I think if you dig down into the Compiler.java code (that's where
I assume
20 matches
Mail list logo
